SPF, DKIM and DMARC explained
Email was designed without any built-in way to check the sender: anyone can send a message claiming to come from your domain. SPF, DKIM and DMARC are the three DNS records that close that gap. Together they let a receiving server establish that an email really comes from you — and what should happen when it does not.
They are no longer optional. The major mailbox providers weigh these checks heavily, and a domain without correct authentication sees part of its mail land in the spam folder.
SPF
Sender Policy FrameworkSPF is a DNS record in which the owner of a domain states which servers are allowed to send email on behalf of that domain. The receiving server compares the sending IP address against that list.
A domain may have only one SPF record. Anyone who adds services over time — a mail provider, a newsletter platform, a web shop — sometimes ends up with two records, and then the check fails entirely. Every sending party belongs in that single record.
A second pitfall is the limit on the number of lookups an SPF record may trigger. Stack up many services and that limit is exceeded, so SPF fails anyway.
DKIM
DomainKeys Identified MailDKIM is a digital signature that the sending server adds to every outgoing email and that the recipient verifies with a public key published in DNS. It proves that the message was not altered in transit and really comes from the domain.
DKIM is more robust than SPF because it does not depend on an IP address: a forwarded message stays valid, whereas SPF often fails in that case. The classic mistake is a key that was never published — the server does sign, but the DNS record is missing, so nobody can verify the signature.
DMARC
Domain-based Message Authentication, Reporting and ConformanceDMARC is a DNS record that states what a receiving server should do when SPF and DKIM fail, and where reports about those checks may be sent.
| Policy | What the recipient does | When to use it |
|---|---|---|
p=none | Nothing — the message is handled normally, but you do receive reports. | At the start, to see who is sending on behalf of your domain. |
p=quarantine | Suspicious messages land in the spam folder instead of the inbox. | As soon as you are certain that all your legitimate senders pass. |
p=reject | Messages that fail are refused and arrive nowhere. | As the end state, once everything has run flawlessly for months. |
Going straight to p=reject. Forget a single sender — the accounting package that sends invoices, an old web shop that still sends mail — and from that moment on its mail arrives nowhere, without any warning. Start at p=none, read the reports and only tighten afterwards.
In which order should you tackle it?
| Step | What | Why in this order |
|---|---|---|
| 1 | Inventory your senders | Note every system that sends mail on behalf of your domain: mail provider, web shop, accounting, CRM, newsletter tool. Whatever you miss here will break later. |
| 2 | Set SPF correctly | One record, containing all senders. Check straight away that no second SPF record exists. |
| 3 | Publish DKIM | One key per sending service. Verify that the public key is actually present in DNS. |
| 4 | Start DMARC at p=none | You change nothing about delivery yet, but you do receive reports about who is sending on your behalf. |
| 5 | Read the reports | This is where you discover the sender you missed in step 1 — and sometimes that someone is abusing your domain. |
| 6 | Tighten to quarantine, then reject | Only once all legitimate senders pass. Haste at this step costs you mail. |
How 2mail arranges this for you
You connect your domain and 2mail configures SPF, DKIM and DMARC for the mail that leaves through us. That puts the setup of your sending channel in order — the other services that send on behalf of your domain remain your own inventory. That is exactly what the DMARC reports from step 5 are for.
