SPF, DKIM and DMARC explained
Your team sends from its mailboxes, invoices come from an accounting system and newsletters use another service. Recipients see messages from the same business. The technical question is which systems may send for your domain and how receiving mail servers can check them.
SPF checks the sending server
SPF publishes authorised sending infrastructure in DNS. The receiver checks the sending IP against the rules of the technical sender domain, usually from MAIL FROM. This is not necessarily the visible From address in the mail client. An SPF pass alone therefore does not prove that use of the visible domain is authorised.
A checked domain must not publish multiple competing SPF policies. Existing services need to be combined into an appropriate policy. The standard's DNS lookup limit also matters: many nested include mechanisms can cause evaluation to fail. Do not simply add another SPF policy alongside an existing one.
DKIM checks a signature
With DKIM, the sending service signs selected headers and the message body. A public key in DNS allows verification. The signature includes a domain and a selector used to locate the correct key. Different sending services can therefore use their own keys. DKIM does not encrypt the message content.
DMARC connects authentication to the visible sender
DMARC requires at least one successful path, SPF or DKIM, to align with the domain in the visible From address. The selected mode determines how closely the domains must match. SPF can therefore pass while DMARC fails if SPF authenticates a different domain and no aligned DKIM signature is available.
The domain owner's policy asks receivers how to handle DMARC failures: monitor, quarantine or reject. The receiver ultimately decides how to handle a message. Reports can help with investigation, but do not replace checking each legitimate sending source or guarantee inbox delivery.
Example: the overlooked invoicing system
Suppose a company tests only Outlook and its newsletter service. Both pass. After it tightens DMARC, invoices sent by another platform using the same From domain encounter problems. The inventory was incomplete. Before changing policy, establish whether that service supports an aligned return path or DKIM using your domain.
For each source, record its owner, visible From domain, technical sender domain, DKIM domain and test result. Include printers, the ticketing system, contact forms and CRM. Test forwarding and mailing lists separately because the delivery path or message content can change.
Preparing the change
- Inventory all sending services and assign an owner to obsolete entries.
- Configure SPF and DKIM using instructions from the providers you actually use.
- Receive test messages from every service and inspect Authentication-Results added by your own trusted receiving system.
- Begin with monitoring, evaluate reports and fix failures affecting legitimate senders.
- Approve a stricter policy after testing and assign responsibility for future sending services.
What still needs checking
An authenticated message can still be fraudulent, for example when a genuine account has been compromised. Lookalike domains are a separate problem too. Continue training staff to handle changed payment details and unusual requests. SPF, DKIM and DMARC form part of email operations; they do not replace account security or clear approval processes.