Product
Email authentication for your domain
Email authentication explained: what SPF, DKIM and DMARC records do, example syntax, alignment, and a safe order to publish them for a domain that sends.
A clear four-step setup
Keep your registrar and DNS provider. We show the exact records your domain needs, then make the rest of the workflow simple.
Authentication is the foundation
TXT proves control. MX directs incoming mail. SPF, DKIM and DMARC give receivers evidence that your messages are legitimate.
Why email authentication exists
Anyone can type any address into the From line of an email. Authentication gives receiving servers a way to check that a message claiming to come from your domain was sent by a system you authorised. Three DNS-published standards work together: SPF lists the servers allowed to send, DKIM adds a cryptographic signature, and DMARC ties both to the From address people see and says what to do when the checks fail.
These records matter for domains that send mail. A domain that only receives mail, such as one connected to a Free Domain Mail catch-all inbox, does not need them for receiving.
SPF: who may send
SPF is one TXT record at the domain that lists authorised senders and ends with an all mechanism. Receivers check it against the envelope sender (Return-Path). A hostname may have only one v=spf1 record, and evaluation may use at most 10 DNS lookups through include, a, mx, ptr, exists and redirect.
example.com TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"DKIM: a signature receivers can verify
The sending service signs each message with a private key and adds a DKIM-Signature header. The matching public key is published at selector._domainkey.yourdomain, either as a TXT record (v=DKIM1; k=rsa; p=…) or as a CNAME to a key the provider hosts. Because selectors are chosen by each service, copy them exactly from the provider.
s1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"DMARC: alignment and policy
DMARC passes when SPF or DKIM passes for a domain that aligns with the From domain: in relaxed mode a subdomain counts, in strict mode only the exact domain does. The policy, published at _dmarc, tells receivers what to do with mail that fails: p=none to monitor, p=quarantine to treat it as suspicious, p=reject to refuse it. The rua tag collects aggregate reports so you can see every system sending as your domain.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"A safe order of work
Authentication changes affect real mail, so introduce them one layer at a time.
- List every system that sends as the domain: mailbox provider, newsletters, billing, support desk, website forms.
- Publish one SPF record that covers them all.
- Enable DKIM in each service and publish its selector records.
- Publish DMARC with p=none and read the reports for a few weeks.
- Move to quarantine and then reject once legitimate mail aligns.
Frequently asked questions
Do I need all three records?
For a domain that sends mail, yes: large mailbox providers expect SPF and DKIM, and DMARC for bulk senders. A receive-only domain does not need them to receive.
Will authentication get my mail into the inbox?
It removes a common reason for rejection, but placement still depends on reputation, content and whether recipients want the mail.
Does Free Domain Mail need SPF or DKIM?
No. It is receive-only and never sends mail, so it only needs the TXT ownership record and the MX record.
How do I check my current records?
Run the email health check, which reads MX, SPF, DMARC and a DKIM selector in one report.
Create account
Free Domain Mail only receives email — it never sends or forwards mail on your behalf. Public temporary addresses are deleted after 10 minutes; custom-domain mail is kept for 30 days. Attachments are never stored, only their name, size and type.
Create account →