What are SPF, DKIM and DMARC?

Email was designed in an era of trust, so by default anyone can put your address in the "from" line. SPF, DKIM and DMARC are the records you publish in your domain's DNS to close that gap. They let receiving servers check, in a fraction of a second, that a message claiming to be from you was actually sent with your permission and arrived unaltered.

Each one answers a different question. SPF answers whether the sending server is allowed to send for your domain. DKIM answers whether the message was signed by your domain and left untouched on the way. DMARC answers what should happen when those checks disagree with the address your recipient sees, and asks receivers to report back so you can watch for abuse. None of the three replaces the others; they are layers, and the layers reinforce each other.

SPF	Sender Policy Framework. A DNS record listing the servers and services permitted to send email for your domain.
DKIM	DomainKeys Identified Mail. A cryptographic signature added to each message, verified against a public key in your DNS.
DMARC	Domain-based Message Authentication, Reporting and Conformance. A policy that aligns SPF and DKIM with the visible from-address, sets what to do on failure, and requests reports.

When you send a support reply, the receiving mail server runs the checks in turn. First it looks up your SPF record and asks: is the server that just connected on the approved list for this domain? Then it reads the DKIM signature in the message header and verifies it against the public key published in your DNS, confirming the message is unaltered and genuinely signed by your domain. These two checks can run independently, and a message can pass one while failing the other.

Why DMARC is the keystone

SPF and DKIM each check a technical address that the recipient never sees. A message can pass SPF or DKIM for one domain while showing a completely different address in the from-line. DMARC closes that loophole by requiring "alignment": the domain that passes SPF or DKIM must match the domain your customer actually reads. If neither aligned check passes, DMARC applies your stated policy and refuses, quarantines, or allows the message accordingly.

The reporting half people forget

The R in DMARC stands for reporting, and it is the part that makes the whole system manageable. When you publish a DMARC record with a reporting address, mailbox providers send you aggregate reports showing which sources sent mail as your domain and whether each passed. That is how you spot a forgotten newsletter tool, a billing service or an impersonator sending as you, before you tighten the policy and risk blocking your own legitimate mail.

Easing the policy in stages

The safe order is to start at "p=none" so nothing is blocked while you read the reports, move to "p=quarantine" once every legitimate source is passing, and finish at "p=reject" so forged mail is refused outright. Rushing straight to reject before your reports are clean is the classic way to send your own invoices and support replies to the spam folder, so give each stage time to settle.

A shared support address such as the one behind your contact form is exactly the kind of mailbox spammers like to forge, because customers trust it and act on what it says. When you have no authentication published, a receiving server has no way to tell your genuine reply from a forgery, so it leans on cautious filters. The honest, expected reply to a customer can land in spam simply because nothing proves it is yours.

The pressure has grown sharply. Major mailbox providers now expect bulk senders to authenticate with SPF, DKIM and an enforced DMARC policy, keep complaint rates low, and offer easy unsubscribe on marketing mail. Even for low-volume support, unauthenticated mail is increasingly treated as suspect. An expired or broken record can take a previously reliable address from the inbox to the spam folder overnight, which is why these records belong on the checklist for any business address.

The cost of getting it wrong

When support replies are filtered, customers do not see your answer, assume they have been ignored, and chase again or escalate to a refund or a public complaint. The damage is quiet and easy to miss, because nothing bounces and no error appears in your sent folder. Authentication is cheap insurance against a failure mode you might not notice until reviews and chargebacks start to climb.

You do not need to guess at the state of your domain. The UK National Cyber Security Centre runs a free service, Mail Check, that lets an organisation assess its email anti-spoofing setup and monitor SPF, DKIM and DMARC over time. It is aimed at UK public sector bodies and charities in particular, and many third-party authentication checkers offer a similar one-off look-up for any domain. Either way, the goal is the same: confirm each record exists, is valid, and is enforced rather than left in report-only mode for ever.

1. Confirm an SPF record exists and lists every service that sends for you, including billing, newsletters and your helpdesk.
2. Confirm DKIM signing is switched on at your mail provider and the matching public key is published in DNS.
3. Publish a DMARC record, start at "p=none" with a reporting address, and read the reports for a few weeks.
4. Once legitimate sources pass, tighten DMARC to quarantine and then reject, checking reports at each step.
5. Re-check after any change to your mail provider, sending tools, or DNS host.

Treat these as living records, not a one-off task. Every time you add a tool that sends on your behalf, you may need to update SPF or add a DKIM key, and a forgotten source is the usual reason a clean DMARC report suddenly shows failures.

Alignment	The DMARC requirement that the domain passing SPF or DKIM matches the visible from-address the recipient sees.
Envelope sender	The behind-the-scenes return-path address that SPF actually checks, distinct from the from-line a person reads.
Selector	A short label in a DKIM signature that points to which public key in your DNS should verify the message.
Spoofing	Forging the from-address of a trusted domain. Email authentication exists chiefly to make spoofing detectable.
Deliverability	Whether your mail reaches the inbox. Authentication is the foundation; reputation and content do the rest.