SPF, DKIM and DMARC: set up authentication for your domain
Three records to add in your domain's DNS zone, at the host that manages it. They prove to mailbox providers that your emails really come from you. Without them, your outreach emails land in spam, or do not get through at all.
They are set up when you create your mailboxes at your host, never in Emelia.
| Where | in the domain's DNS zone, at the host that manages it |
| When | when you create the mailboxes, before the first campaign |
| SPF | one TXT record on the domain, and only one |
| DKIM | a key provided by your email provider, to publish and then enable |
| DMARC | a TXT record named _dmarc, set to p=none |
| Check | a public tool, such as mail-tester.com or dnschecker.org |
What these three records are for
An email is a letter on which anyone can write whatever sender address they like. To unmask impostors, Gmail, Outlook and the others check three pieces of information that you publish in your domain's DNS.
- SPF is the guest list. It says which servers are allowed to send email on behalf of your domain. A message sent from a server that is not on the list is suspicious.
- DKIM is the wax seal. Your email provider signs every email, and the recipient checks the signature with a key published in your DNS. It proves the message comes from you and was not altered on the way.
- DMARC is the doorman's orders. It says what to do with a message that claims to come from you but fails both previous checks (let it through, quarantine it, reject it), and who to send reports to.
There is also a fourth record, MX. It is not authentication: it is your mailbox's street address, telling the world which server to deliver your domain's mail to. Without it, you do not receive your prospects' replies.
Why it is essential for outreach
Since 2024, Google and Yahoo require SPF, DKIM and DMARC from senders who send in volume, and Microsoft followed in 2025 for Outlook.com and Hotmail. In outreach, you write to strangers who are not expecting you: you have no margin. A poorly authenticated domain lands in spam, however much care went into the message.
Something else to understand: Emelia does not send your emails from its own servers. It connects to your mailbox the way an email client would, and your emails leave through your provider's servers. Authentication is therefore your provider's, and there is nothing from Emelia to add.
It is the reflex of people coming from a newsletter tool. Emelia has no sending server, no DKIM key and no IP address to authorize. An include pointing to Emelia would be invalid, and it would waste one of the ten DNS lookups an SPF record is allowed.
The values to add, provider by provider
In every case, you work in the domain's DNS zone, at the host that manages it: the one where you bought the domain, or the one its name servers point to. It is not necessarily the one hosting your mailboxes: a domain bought from one registrar can perfectly well carry Google Workspace mailboxes. The records then go at that registrar, with Google's values.
Google Workspace
SPF: a TXT record on the domain itself (name @, or the field left empty, depending on the host).
Google Workspace SPF : If the domain already has an SPF record, do not create a second line: add include:_spf.google.com to the existing one.
v=spf1 include:_spf.google.com ~all- DKIM: in the Google Admin console (admin.google.com), open Apps, Google Workspace, Gmail, then Authenticate email, and pick your domain.
- Click Generate new record (2048-bit key). Google shows a TXT record named
google._domainkey: copy its name and value into your DNS zone. - Then go back to the console and click Start authentication. Until you make that last click, Google does not sign your emails, even if the record is in your DNS.
Microsoft 365
SPF: a TXT record on the domain.
Microsoft 365 SPF : Same rule: one SPF per domain, complete the existing one if there is one.
v=spf1 include:spf.protection.outlook.com -all- DKIM: in the Microsoft Defender portal, on the DKIM settings page (security.microsoft.com), select your domain. Microsoft shows two CNAME records,
selector1._domainkeyandselector2._domainkey, with values specific to your tenant: copy them as they are into your DNS zone. - Once the CNAMEs have propagated, go back to the same page and turn on Sign messages for this domain with DKIM signatures.
- Without that, Microsoft signs your emails with its technical
onmicrosoft.comdomain, not with yours.
OVH
When you activate an OVH email offer on a domain whose DNS OVH manages, OVH adds the SPF and DKIM itself. DKIM takes the form of two CNAMEs, ovhmo-selector-1._domainkey and ovhmo-selector-2._domainkey. Check that they are there, without duplicating them.
On a brand-new mailbox, allow up to 24 hours before DKIM shows up. The only record to add yourself is DMARC.
OVH SPF, added automatically : The value you should find in your zone. Only add it if it is missing.
v=spf1 include:mx.ovh.com ~allOther hosts
Cloudflare, GoDaddy, IONOS, Gandi, Namecheap, Squarespace… The interface changes, the logic does not. Look for “DNS zone”, “DNS records” or “DNS management”, then “Add record”. Three fields come up everywhere: the type (TXT or CNAME), the name (also called host or subdomain) and the value (or target).
SPF and DKIM depend on your email provider, not on the domain's host: use the values your provider gives you. If your mailboxes come from a reseller that creates the domain and the mailboxes together, these records are often already in place: check before adding any.
| Record | Type | Name (host) | Value |
|---|---|---|---|
| SPF | TXT | @ (or empty) | your email provider's |
| DKIM | TXT or CNAME | given by your provider, e.g. google._domainkey | given by your provider |
| DMARC | TXT | _dmarc | v=DMARC1; p=none; sp=none; |
DMARC, the same for everyone
DMARC is the only one of the three that does not depend on your provider. Create a TXT record named _dmarc, with one of these two values. One DMARC per domain.
Record name : With the underscore. Your host adds your domain name after it, do not type it again.
_dmarcValue, minimal version : Enough to be authenticated.
v=DMARC1; p=none; sp=none;Value, with reports : Replace the address with one on this domain. You will receive daily reports from mailbox providers: useful for a technician, pointless otherwise.
v=DMARC1; p=none; sp=none; rua=mailto:name@yourdomain.comp=quarantine and p=reject look safer, but on an outreach domain they get emails sent to spam or rejected at the slightest deviation. Stay on p=none: you are authenticated, and that is what counts.
Check your records
After fixing something in your DNS, wait one to two hours before checking again.
Check it with public tools
- mail-tester.com: send an email to the address it gives you; it scores your message and details SPF, DKIM and DMARC.
- dnschecker.org: shows a record's value as seen from around the world (TXT for SPF and DMARC). Handy to know whether a change has propagated.
- MXToolbox: checks the syntax of your SPF and DMARC, and whether your domain is on a blocklist.
- In Gmail: open an email received from your mailbox, ⋮ menu, Show original. The SPF, DKIM and DMARC lines should say PASS.
The mistakes we see most often
- Two SPF records on the same domain, for example the old one and the new one. A domain is allowed only one SPF: with two, it is invalid. Merge them into a single line holding every
include. - An SPF left on the former host after switching mailboxes. It is the most common mistake.
- DKIM published but never enabled, in the Google console (Start authentication) or at Microsoft. The record is in the DNS, but emails are not signed.
- DMARC too strict too early:
p=rejectorp=quarantineon a new domain gets emails rejected. - Two DMARC records, or a DMARC under the wrong name: you need exactly one, named
_dmarc. - The secondary domain forgotten: you authenticated your main domain, but you prospect from another one. Every sending domain needs its own SPF, DKIM and DMARC, and its own tracking domain.
- The domain name typed again in the name field: the host already adds it, and you end up with
_dmarc.yourdomain.com.yourdomain.com. - Checking too early: a DNS change takes from a few minutes to a few hours to propagate, and hosts often quote up to 24 hours. Wait before drawing conclusions.
- Two sets of MX records, Google and Microsoft, on the same domain: part of your mail goes to the wrong provider, and you lose replies.
Frequently asked questions
The questions we get asked on this topic, answered briefly.
Is DMARC mandatory to send with Emelia?
It does not block campaigns, but we recommend it: it slightly improves deliverability, and Google and Yahoo expect it from volume senders. As long as a DMARC record on p=none exists, you are fine.
I get dozens of DMARC reports a day, how do I stop them?
They go to the address after rua= in your DMARC record. Change it to a dedicated mailbox, or remove the rua= part: it has no effect on deliverability.
My domain is with one host and my mailboxes with another, is that a problem?
No. The records go wherever the domain's DNS zone is managed, with your email provider's values. No domain transfer is needed.
Do I need to add anything for Emelia in my DNS?
Not for authentication: no SPF include, no DKIM key, no IP. The only Emelia-specific record is the tracking domain CNAME, which is for link tracking, not authentication.
How long does propagation take?
Usually from a few minutes to a few hours. Hosts often quote up to 24 hours, and on a brand-new OVH mailbox DKIM can take a day to appear. Check on dnschecker.org.
Read next