← Board
SC-19Done

Mail from scofti.com landing in spam

Two sending paths, two reputations. The webmail one is unsigned.

The contact form works and mail arrives — SC-19 is about where it arrives. delivered in Resend means the receiving server accepted the message. It says nothing about whether it was filed under spam, and a contact form nobody notices is the same as a contact form that does not work.

Not urgent. Deliberately left for a day when there is a little history to look at rather than one test message.

Two records that need attention

Both exist already and neither is right yet:

scofti.com        TXT  "v=spf1 include:_spf.porkbun.com ~all"
_dmarc.scofti.com TXT  "v=DMARC1; p=none;"

SPF must stay a single record. Resend's include belongs merged into the existing line, never published as a second v=spf1. Two SPF records are a permanent fail and would take the Porkbun forwarding down with them.

DMARC is a placeholder doing nothing. p=none with no rua= means no enforcement and no reports, so a failure is invisible. Add a reporting address first and read what comes back:

v=DMARC1; p=none; rua=mailto:prefect@scofti.com; fo=1;

Leave p=none until those reports show SPF and DKIM passing for real mail. Tightening to p=quarantine or p=reject before that can bounce legitimate mail, forwarding included.

The check

  1. Send through the live form to an address whose raw headers you can read — a Gmail account is easiest.
  2. Show original. It has to say SPF: PASS, DKIM: PASS and DMARC: PASS. Two of three is not enough; DKIM is the one that survives forwarding.
  3. Confirm it is in the inbox, not spam or promotions.
  4. Confirm Reply addresses the person who wrote rather than the site. If reply_to is wrong every answer goes nowhere and nobody finds out.
  5. Worth a second opinion: mail-tester.com scores a message out of ten and names what is missing.

If anything fails, the fix is DNS rather than code — the sending side is already verified in Resend, with open and click tracking off.

Verified: the round trip works

Sent from the live form on scofti.com. It arrived in the Porkbun mailbox for prefect@scofti.com, inbox, not spam. Replying from that webmail reached a personal Gmail inbox, also not spam.

The reply is the part worth noting: it went to the address that filled in the form rather than back to the site, which is reply_to doing its job. A form whose replies go nowhere fails silently, and nobody finds out.

What that does not cover

The contact mail was judged by Porkbun, not by Gmail — it was delivered to a mailbox there and read in webmail, so it never passed through Gmail's filter. Only the reply did, and that was sent by Porkbun, not by Resend. So nothing yet confirms how a Resend-sent message is judged by a big provider, and nothing has read the authentication headers.

Two things left, in order of how much they are worth:

  1. Add rua= to the DMARC record. This is the one with lasting value. The record is still p=none with no reporting address, so it enforces nothing and reports nothing. If SPF or DKIM drifts later — a record edited, a key rotated — mail starts failing and nothing says so.

    v=DMARC1; p=none; rua=mailto:prefect@scofti.com; fo=1;

  2. Read the headers once. Point CONTACT_TO at a Gmail address temporarily, or at a mail-tester.com address, submit one message, confirm SPF: PASS, DKIM: PASS, DMARC: PASS under Show original, then set it back. Five minutes, and it turns "it seems to work" into something checked.

Neither is urgent. The form works and mail is reaching a person.

The other sending path

A message composed in Porkbun webmail to a personal Gmail lands in spam, while a reply from the same mailbox did not. That is not a contradiction — Gmail leans heavily on an existing thread the recipient already took part in. A cold message is judged on authentication and reputation alone, and those are thinner than they look.

scofti.com sends by two different routes, and they do not share a reputation:

| Route | Used for | SPF | DKIM | | --- | --- | --- | --- | | Resend | the contact form | not needed | signed — resend._domainkey | | Porkbun | anything written in webmail | passes, via the include | none found |

The domain publishes exactly one DKIM selector, resend._domainkey. Probing the common generic and Porkbun selector names turned up nothing else, so mail sent from webmail is going out unsigned. It still passes DMARC, but only because SPF aligns — there is no second leg to stand on.

Add a brand-new domain with no sending history and an SPF that ends in ~all, and that is a thin profile for a stranger's inbox.

What to do, in order

  1. Find out whether Porkbun can sign outbound mail. If their email product offers DKIM, turn it on and publish the selector. This is the one real gap and the only item here that is a setting rather than a wait.
  2. Add rua= to DMARC, so there is any visibility at all: 
    v=DMARC1; p=none; rua=mailto:prefect@scofti.com; fo=1;
    Without it, nothing reports what is passing or failing, and this whole question stays guesswork.
  3. Give it time. Domain reputation is earned, not configured. A two-day-old domain sending cold mail to Gmail gets suspicion regardless of perfect records, and it improves with steady, low-volume, replied-to sending.
  4. Consider not sending cold mail from here yet. The contact form works and replies land. If something important has to reach a stranger this week, a personal Gmail address will do it and scofti.com will not.

Do not reach for -all or a stricter DMARC policy to force this. Tightening before the reports come back clean bounces real mail, forwarding included, and this domain's forwarding is how the contact form reaches anyone.

Parked — nothing is being sent from webmail

There is no outbound mail to send from this domain for the foreseeable future, so the unsigned webmail path is not a problem to solve. It is only worth knowing that it exists, and that anything composed there will likely land in a stranger's spam folder until it is signed and the domain has some history.

The path that matters works. The contact form goes out through Resend, signed, and reaches the mailbox in the inbox. That is the only route the site actually depends on.

Confirmed by probing twenty-three common selector names: resend._domainkey is the only DKIM key this domain publishes.

All that is left

Edit the existing _dmarc.scofti.com record — it is already there, and that is the point: p=none; with no reporting address enforces nothing and reports nothing.

v=DMARC1; p=none; rua=mailto:prefect@scofti.com; fo=1;

p=none stays, so nothing starts bouncing. It just means that if the contact form's authentication ever drifts — a key rotated, a record edited — a report says so, instead of mail quietly failing and nobody finding out for a month.

One edit. Then this can close.

Done — reporting is on

The record is live and reads:

v=DMARC1; p=none; rua=mailto:prefect@scofti.com; fo=1;

Verified against DNS rather than the registrar's form, because a typo in the reporting address fails the way this whole ticket is about — silently, with the reports going nowhere and everything looking fine.

Two things to expect, so neither is a surprise:

Nothing here enforces anything — p=none is unchanged, deliberately. The point was never to start blocking mail; it was to stop being unable to see.

Addendum: a later webmail message reached the inbox

A second message composed in webmail to the same personal Gmail landed in the inbox rather than spam, shortly after the DMARC edit.

Do not read that as fixed. Gmail weighs per-recipient history heavily, and that account now has plenty of it — mail received from this address, a reply sent into a thread with it, and possibly a spam-folder rescue, which is about the strongest signal a person can give. None of that transfers to someone else's inbox.

The DMARC change may have helped slightly; so would Gmail simply learning. Both happened in the same window, and attributing it to either would be a guess.

What has not changed: webmail still sends unsigned. If cold mail from this domain ever matters, DKIM on the Porkbun path is still the gap, and a friendly inbox proves nothing about it.