A customer forwards an invoice that appears to have come from your accounts team, except nobody sent it and the bank details are wrong. It carried your domain in the From line, and nothing stopped it. Email was designed without a way to prove who sent a message, and SPF, DKIM and DMARC are the three records added later to close that gap. Set up correctly, they make it very hard for anyone to send mail as you. Set up carelessly, they either do nothing or block your own mail.
SPF: which servers may send for your domain
The Sender Policy Framework, or SPF, is a text record in your domain’s DNS that lists the servers and services allowed to send email on behalf of that domain. A receiving server looks at the domain in the envelope sender (the return path used for bounces, not necessarily the address the recipient sees) and checks whether the sending server is on that list. If it is, SPF passes; if not, the record’s final qualifier says whether that is a soft or hard failure.
Two things trip up small businesses. First, a domain may have only one SPF record; publishing two, which happens when a second provider’s instructions are pasted beside the first, makes both invalid. Second, SPF has a limit of ten DNS lookups when it is evaluated, and every included service consumes some of them. Add a marketing platform, a ticketing system and a payroll provider, and the limit is reached quietly.
DKIM: a signature that proves the message was not altered
DomainKeys Identified Mail, or DKIM, attaches a cryptographic signature to each outgoing message using a private key held by the sending system. The matching public key is published in DNS under a named selector for your domain. The receiving server fetches that key and verifies the signature; if the signed headers and body have not been altered in transit, DKIM passes.
DKIM has a practical advantage over SPF: it survives forwarding, because the signature travels with the message even when the forwarding server is not on your SPF list. Each service that sends for you needs its own DKIM key configured.
DMARC: policy, alignment and reporting
Domain-based Message Authentication, Reporting and Conformance, or DMARC, ties the other two together and adds what they lack: a policy for receivers to apply when checks fail, and a way for you to see what is happening.
Alignment
Alignment is the piece most explanations skip. It is not enough for SPF or DKIM to pass; the domain that passed must match the domain in the From header that the recipient actually sees. A message can pass SPF for a marketing platform’s own bounce domain while showing your domain in the From line, and DMARC treats that as a failure. In relaxed mode a subdomain of your domain is enough; in strict mode it must match exactly. A message passes DMARC when at least one of SPF or DKIM both passes and aligns.
Policy progression
The DMARC record carries a policy: none, quarantine or reject. “None” asks receivers to take no action but to send you reports. “Quarantine” asks them to treat failing mail as suspicious, typically sending it to junk. “Reject” asks them to refuse it. The design assumes you start at none, learn from the reports, fix what is broken and only then move up.
Reporting
With a reporting address in your DMARC record, participating receivers send aggregate reports summarizing which sources sent mail as your domain and whether each passed or failed. These arrive as machine-readable files, are far easier to interpret through a tool than by hand, and reveal every legitimate service you forgot about as well as every source impersonating you.
Rolling it out without breaking your own mail
The safe sequence is deliberate. Inventory every system that sends email using your domain: the mail platform, marketing tools, the accounting package that emails invoices, the CRM, the help desk, website contact forms, printers and scanners, monitoring systems. Publish a single correct SPF record covering them, and check the lookup count. Configure DKIM signing for each service that supports it. Publish DMARC at a policy of none with a reporting address, and let it run for a few weeks. Read the results, fix the senders that fail or do not align, and repeat until legitimate mail is clean. Then move to quarantine, watch again, and finally to reject.
The common mistakes are all shortcuts around that sequence: jumping straight to reject and silently losing invoices, publishing a second SPF record for a new tool, forgetting the scanner that emails customers, or publishing DMARC with no reporting address. Our secure email solutions work follows this progression because the goal is protection that holds, not a record that exists.
Common questions
Do I need all three of SPF, DKIM and DMARC?
Yes, for real protection. SPF and DKIM are the checks; DMARC is the policy that tells receivers what to do when they fail and the reporting that shows you what is happening. Without DMARC, a failed SPF or DKIM check has no defined consequence, and you have no visibility of who is sending as your domain. Together they are the accepted standard.
Will DMARC stop all phishing that uses our name?
It stops mail that uses your exact domain in the From line without authorization, which is the most damaging kind. It does not stop look-alike domains that swap a letter, display names showing your company name over another address, or mail from a compromised legitimate mailbox. Those need filtering, awareness training and multi-factor authentication alongside the DNS records.
How long does it take to reach a reject policy?
Long enough to see every legitimate sender show up in the aggregate reports and to fix each one. For a small organization with a handful of sending services that is often a few weeks at a policy of none, a further period at quarantine, and then reject. Rushing is how businesses block their own invoices, so the timeline should follow the data, not the calendar.
What is SPF alignment and why does it fail?
DMARC checks that the domain which passed SPF, taken from the envelope sender used for bounces, matches the domain the recipient sees in the From header. Many third-party services send using their own bounce domain, so SPF passes but does not align. The fix is usually to configure a custom return-path domain with the service, or to rely on DKIM alignment for that sender.
If you are not sure whether your domain is protected, or a DMARC record was published years ago and never moved past none, our secure email solutions page describes how we inventory senders and progress the policy safely, and you can contact us to have your current records checked.
