Skip to content
NewHost
Menu

SPF, DKIM and DMARC Explained With Example Records for SA Domains

SPF, DKIM and DMARC explained in plain English, with correct example DNS records, a safe rollout plan and fixes for the most common email authentication errors.

By NewHost team · · 6 min read

SPF, DKIM and DMARC are three DNS records that prove your email really comes from your domain. SPF lists the servers allowed to send for your domain, DKIM adds a cryptographic signature to each message, and DMARC tells receiving servers what to do when a message fails those checks, and sends you reports about it. Together they improve deliverability and make it much harder for criminals to send fake invoices in your name.

Below you will find what each record does, correct example records for example.co.za, and a rollout plan that will not break your email.

Why email authentication matters

Email was designed without any built-in way to check who a sender is. Anyone can type your address into the "From" line. Authentication fixes this in two ways:

  • Deliverability. Large mailbox providers treat unauthenticated mail with suspicion and are increasingly strict about it, especially for businesses that send a lot of mail.
  • Protection against spoofing. Invoice and payment-change fraud often relies on emails that look like they come from a real supplier. A strict DMARC policy tells receivers to reject those forgeries.

SPF - Sender Policy Framework

SPF is a TXT record on your domain that lists which servers may send mail using your domain in the envelope sender (the "return path").

example.co.za.    3600    IN    TXT    "v=spf1 mx include:_spf.mailprovider.example include:_spf.newsletter.example ~all"

Reading it left to right:

Part Meaning
v=spf1 This is an SPF record
mx The servers in my MX records may send
include:... Also allow the servers listed in another domain's SPF record (your email provider, newsletter tool, etc.)
~all Anything else is a "soft fail" (treat as suspicious)
-all Alternative: anything else is a hard fail

SPF rules to remember

  • Only one SPF record per domain. Two v=spf1 records make SPF fail. Merge them.
  • 10 DNS lookup limit. Each include, a, mx and redirect counts towards a limit of 10 lookups. Too many includes causes a "permerror".
  • SPF checks the return path, not the visible From. That is why DMARC is needed to connect SPF to the address people actually see.

DKIM - DomainKeys Identified Mail

DKIM adds a digital signature to the headers of every outgoing message. Your email provider signs with a private key; receiving servers fetch the matching public key from your DNS and verify that the message was not altered and was authorised by your domain.

The public key is published at <selector>._domainkey.<your domain>:

default._domainkey.example.co.za.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3..."
  • The selector (default here) is chosen by your provider. You can have several DKIM records with different selectors, one for each service that sends as you.
  • The p= value is the public key. Copy it exactly from your provider; it is usually long.
  • Some providers ask you to add a CNAME instead of a TXT record, so they can rotate keys for you:
selector1._domainkey.example.co.za.    3600    IN    CNAME    selector1.dkim.mailprovider.example.

Use whichever form your provider specifies. Exact selectors and key values always come from your email provider.

DMARC - Domain-based Message Authentication, Reporting and Conformance

DMARC ties it together. It checks that SPF or DKIM passes and that the passing domain aligns with the domain in the visible From address. It then applies your policy and sends you reports.

_dmarc.example.co.za.    3600    IN    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
Tag Meaning
v=DMARC1 This is a DMARC record
p=none Monitor only, do not change delivery
p=quarantine Treat failing mail as suspicious (usually spam folder)
p=reject Reject failing mail outright
rua=mailto: Where to send daily aggregate reports
pct= Apply the policy to a percentage of failing mail (for gradual rollout)
sp= Policy for subdomains, if different
fo=1 Ask for failure information when any check fails

The DMARC specification and a list of resources are available at dmarc.org.

A safe rollout plan

Jumping straight to p=reject can block your own legitimate mail from a service you forgot about. Roll out in stages:

  1. Inventory every service that sends as your domain. Your mailboxes, website contact forms, online store, accounting software, newsletter platform, CRM and helpdesk.
  2. Set up SPF with includes for each service.
  3. Turn on DKIM in your email provider and in every other service that supports it.
  4. Publish DMARC with p=none and a reporting address.
  5. Read the reports for a few weeks. Aggregate reports are XML files; a DMARC report viewer makes them readable. Fix any legitimate source that fails.
  6. Move to p=quarantine, optionally with pct= to start with a portion of mail.
  7. Move to p=reject once you are confident everything legitimate passes.

Checking your records

dig example.co.za TXT +short
dig default._domainkey.example.co.za TXT +short
dig _dmarc.example.co.za TXT +short

Then send a message to an external mailbox and inspect the headers. Look for spf=pass, dkim=pass and dmarc=pass in the Authentication-Results header.

Common problems and fixes

  • Two SPF records: merge into one v=spf1 record.
  • SPF permerror (too many lookups): remove includes for services you no longer use, or ask providers for a narrower include.
  • DKIM fails after a DNS copy: the key was truncated or split incorrectly. Paste it again.
  • DMARC fails although SPF passes: the SPF domain does not align with the From domain. Enable DKIM for that service with your own domain.
  • Website contact form mail fails: send it through authenticated SMTP from a real mailbox rather than the server's default mail function.

For more on landing in the inbox, read why your emails go to spam. If you are still setting up mailboxes, start with how to set up email on your own domain, and for a wider look at record types see DNS records explained.

Frequently asked questions

Do I need all three, or is SPF enough?

You need all three. SPF alone does not protect the visible From address and breaks when mail is forwarded; DKIM survives forwarding; DMARC connects both to the From address and lets you enforce a policy.

Can I have more than one DKIM record?

Yes. Each sending service uses its own selector, so you can publish several DKIM records side by side. You can only have one SPF record and one DMARC record for a domain.

Will p=reject stop all spam?

No. DMARC stops other people from sending mail that pretends to be from your exact domain. It does not stop spam from other domains or lookalike domains.

Where do I get my DKIM key?

From your email provider's control panel or setup instructions. The provider holds the private key and gives you the public key or a CNAME target to publish in DNS.

How long before DMARC reports arrive?

Most receivers send aggregate reports about once a day, so expect the first reports within a day or two of publishing the record.

Want a host that makes DNS records easy to manage? NewHost email hosting gives you mailboxes on your own domain, with every DNS record editable in one dashboard.

Related guides

Ready to launch on NewHost?

Choose a plan and go live today, or tell us what you need and we'll recommend the right setup.