Is an SPF record enough on its own?

No. SPF only checks the technical sender (Return-Path) and often fails with forwarding. Only DMARC protects the visible sender address, and major mailbox providers require SPF, DKIM and DMARC from bulk senders.

What happens with more than 10 DNS lookups in the SPF record?

The receiving server aborts the check with the result permerror. SPF is then treated as failed, which can hurt deliverability and the DMARC result.

Should I use -all or ~all?

Once all legitimate senders are in the record, -all is the clearer choice. ~all is suitable for the transition phase; the actual protection against spoofing comes from DMARC with quarantine or reject.

How quickly can I switch to p=reject?

Plan for several weeks. Stay at p=none until the reports show that all your own sending services pass SPF or DKIM and are aligned, then tighten the policy step by step.

How to Set Up SPF, DKIM and DMARC (With Examples)

Why email authentication is a must today

The email protocol SMTP basically allows anyone to enter any sender address. SPF, DKIM and DMARC give receiving servers a way to check whether a message really comes from your domain. There are three concrete reasons for this:

Deliverability: Unauthenticated emails are more often classified as spam or rejected.
Requirements of the major providers: Since February 2024, Gmail and Yahoo require at least SPF or DKIM from all senders. Bulk senders (at Google: more than 5000 messages per day to Gmail addresses) need SPF, DKIM, a DMARC record of at least p=none, and authentication aligned with the sender address. Since May 2025, Microsoft also requires SPF, DKIM and DMARC for Outlook.com, Hotmail.com and Live.com from senders with more than 5000 messages per day.
Protection against spoofing: Only with a DMARC policy of quarantine or reject can recipients reliably filter out forged emails using your domain.

How the three standards work together

SPF lists the servers that are allowed to send for your domain. It checks the domain in the technical sender (Return-Path).
DKIM signs each message cryptographically. You publish the public key in DNS.
DMARC links both to the visible sender address (From). A message passes DMARC if SPF or DKIM succeeds and the checked domain matches the From domain (alignment). DMARC also defines what happens to messages that fail and provides reports.

All three are TXT records. You can find the basics of record types in our guide DNS records explained.

Setting up SPF

Structure of an SPF record

The SPF record is a TXT record on the domain itself:

example.ch.  3600  IN  TXT  "v=spf1 mx include:_spf.google.com ip4:192.0.2.25 -all"

The mechanisms are evaluated from left to right, and the first match wins:

ip4: / ip6: allow individual addresses or networks
a and mx allow the addresses of the domain’s A or MX records
include: pulls in a provider’s SPF record
all at the end applies to all remaining servers

The qualifiers before “all”

Qualifier	Result	Use
`-all`	fail	Recommended once all senders are covered
`~all`	softfail	Transition phase during rollout
`?all`	neutral	Practically ineffective
`+all`	pass	Allows every server in the world to send: never use it

The 10 DNS lookup limit

During evaluation, an SPF record may trigger at most 10 DNS lookups. include, a, mx, ptr, exists and redirect all count, including nested includes inside providers’ records. ip4, ip6 and all do not count. If the limit is exceeded, the check ends with permerror and SPF is treated as failed.

How to stay under the limit:

Remove includes for services you no longer use.
Replace a and mx with ip4/ip6 if the addresses are stable.
Let newsletter or CRM tools send from their own subdomain (e.g. news.example.ch) with a separate SPF record.
Avoid ptr, it is deprecated.

Only one SPF record per domain

If there are two TXT records starting with v=spf1, the result is also permerror. This often happens when a new service is set up and its template is added as an extra record. Instead, add the new service’s include to the existing record.

Setting up DKIM

Understanding selectors

Every signed message contains the domain (d=example.ch) and a selector (s=google) in its header. The recipient then looks up the key under selector._domainkey.example.ch. Several selectors can exist in parallel, typically one per sending service. This also allows key rotation without interruption. Use 2048-bit keys.

google._domainkey.example.ch.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

How common providers publish DKIM

Google Workspace: In the Admin console, generate a key under Gmail “Authenticate email”. The default selector is google. Publish the TXT record shown, then start authentication in the console.
Microsoft 365: Here you set two CNAME records, selector1._domainkey and selector2._domainkey, pointing to targets in your Microsoft tenant. The exact values are shown in the Microsoft Defender portal, where you then enable DKIM. Microsoft handles key rotation.
Hostpoint: If your domain and DNS are with the Swiss host Hostpoint, enable DKIM for mail hosting in the Control Panel and the record is added to the zone. If you manage DNS elsewhere, copy the selector and key to your DNS provider manually.
Infomaniak: DKIM is enabled in the Manager under the mail service. If your DNS is not hosted at Infomaniak, add the TXT record shown yourself.

Selector names cannot be listed from the outside. So check each service’s documentation to see which selector it uses.

Setting up DMARC

The DMARC record always lives under _dmarc:

_dmarc.example.ch.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.ch"

The most important tags:

p: policy for the domain: none (monitor only), quarantine (spam folder) or reject (refuse)
rua: address for daily aggregate reports. If it is on a different domain, that domain must authorize receiving them via DNS.
sp: policy for subdomains, otherwise p applies
pct: percentage of messages the policy is applied to (default 100)
adkim / aspf: alignment for DKIM or SPF, r (relaxed, subdomains count as matching, the default) or s (strict, exact match)

The safe path to p=reject

Monitor: Start with p=none and rua, and review the reports for two to four weeks. They show every source sending with your domain: CRM, newsletter, accounting, contact forms.
Fix: Set up SPF and DKIM correctly for each legitimate source, aligned with the From domain.
Quarantine: Switch to p=quarantine, if needed starting with pct=25 and then increasing.
Reject: If the reports stay clean, switch to p=reject.

_dmarc.example.ch.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ch"

Protect domains that never send email with v=spf1 -all, a DMARC policy of p=reject and optionally a null MX (0 .).

MTA-STS and TLS-RPT

While SPF, DKIM and DMARC secure outgoing mail, MTA-STS protects incoming mail: sending servers must establish an encrypted connection with a valid certificate to your MX servers. This requires a TXT record and a policy file at https://mta-sts.example.ch/.well-known/mta-sts.txt.

_mta-sts.example.ch.  3600  IN  TXT  "v=STSv1; id=20261002"

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

TLS-RPT delivers reports about failed TLS connections. Start MTA-STS with mode: testing, review the reports and then switch to enforce.

_smtp._tls.example.ch.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.ch"

Checklist

All services that send email with your domain identified
Exactly one SPF record, at most 10 lookups, ending with -all or ~all
DKIM active for every sending service, with 2048-bit keys
DMARC published with rua, starting with p=none
Reports reviewed, then quarantine and reject
Non-sending domains protected with -all and p=reject
Optional: MTA-STS and TLS-RPT set up

NetScanner’s email checker tests MX, SPF including the lookup count, DMARC, common DKIM selectors as well as MTA-STS, TLS-RPT and BIMI. You can check individual TXT records with the DNS lookup. If you don’t see a change yet, our guide to DNS propagation helps; when switching providers, use the domain migration checklist.

How to set up SPF, DKIM and DMARC correctly