Prove you own the domain you send from

Mail leaves a domain that has never published an authentication record, and enough of it arrives that nobody looks again. The failures are invisible from the sending side. No bounce comes back. No error, no complaint, just an invoice somebody later swears never came and a junk folder nobody thought to search.

For years I filed authentication under things that only matter at volume. That is wrong in a specific way: the filter on the other side has no idea what your volume is. It cannot see your intentions either. It sees a message claiming to be from your domain, arriving from a machine it does not recognise, carrying no proof. It has to decide in milliseconds. Given no evidence it guesses, and the guess is not in your favour.

Deliverability is the plain question of whether your mail lands in the inbox instead of the spam folder or the bin. Authentication is most of that answer. Three records do the work, and they are not interchangeable.

The rules

SPF states which servers may send mail using your domain. It is one DNS TXT record on the domain itself, listing your sending services. A receiver takes the server that actually connected, checks it against your list, and either finds it or does not. SPF says nothing about the message. It only vouches for the postman.

DKIM proves the message was signed by someone holding your key and has not been altered since. Your sending service holds a private key and signs each message. The matching public key sits in DNS under a selector name your provider gives you. The receiver fetches the key, checks the signature, and now knows the body and headers are the ones you sent. SPF survives no forwarding. DKIM usually does.

DMARC tells receivers what to do when the other two fail, and asks them to report back. It also enforces alignment, which is the part most people miss. A message can pass SPF for your provider's domain while the From address shows yours. DMARC refuses that. The authenticated domain has to match the one your reader sees.

A missing record is not neutral, it is suspicious. Mail hosts have spent years teaching their filters that unauthenticated mail from an ordinary business domain is usually fraud. No SPF, no DKIM, no DMARC means no evidence. A filter with no evidence is a filter with a spam folder. Receipts, password resets and invoices all go the same way.

Set one sending identity per business before you set anything else. I run separate sending identities across every business rather than one shared sender for all of them. It is dull and it takes an afternoon. It also means a problem on one domain stays on that domain instead of taking the others down with it. At 850 or so domains under management, the alternative is not survivable.

Do not assert that it works. Read it back. I have a standing rule for every system I touch. Verify against the live thing before claiming anything, and report a failed check as unverified rather than clean. Your provider's green tick is their opinion. The DNS answer is the fact.

Do it now

Add the SPF, DKIM and DMARC records your sending service gives you. Then check them yourself, from a machine that is not your provider's dashboard.

# SPF — one record, on the bare domain
dig +short TXT example.com | grep spf1

# DKIM — selector comes from your provider
dig +short TXT selector1._domainkey.example.com

# DMARC — always on the _dmarc subdomain
dig +short TXT _dmarc.example.com

Start DMARC in monitoring mode so you see reports before you break anything:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

Leave it at p=none for two weeks. Read the aggregate reports. Move to p=quarantine, then p=reject, once the reports show your own mail passing and nothing legitimate failing.

A worked example

Say you run a high-street florist with an online shop at example.com. The shop sends order confirmations and delivery updates through an email service. The monthly newsletter goes out through the same service. Staff answer customers from ordinary shop mailboxes.

That is two services sending as the shop, the email service and the mailbox host. You publish the records each one gives you, start DMARC in monitoring mode, and read all three back.

$ dig +short TXT example.com | grep spf1
"v=spf1 include:spf.email-service.example include:spf.mailbox-host.example ~all"
$ dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
$ dig +short TXT mailhost1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu9..."
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Two services, one SPF line, and nothing taken on trust.

The failure you will hit

You will publish a second SPF record for a new sending service and break the first. A domain is allowed exactly one SPF record. Two records is a permanent error. Receivers treat the whole thing as failed, which is worse than having none. Merge the services into a single v=spf1 line. Watch the lookup limit too. RFC 7208 caps SPF evaluation at ten DNS lookups, and chained include: entries eat that allowance faster than you expect.

Not for you if

You send from a free mailbox at a big provider and have no domain of your own. There is nothing here to configure and nothing to prove.

Authentication done, step two separates the streams. The Vault is the paid membership the rest of this track sits behind, and the price is on the page.