SPF: who may send?
A list of the servers allowed to send messages for your domain. The recipient checks whether the message comes from one of them.
Guide · Email
Three records in your domain’s DNS settings decide whether your messages arrive and whether others can send in your name. Setting them up takes an afternoon. This guide explains the three terms and takes you step by step to the strictest level.
By Paul Czichos, consulting and project support at czichos.net GmbH · Updated
Why it matters
Since February 2024, Google and Yahoo have required at least SPF or DKIM from all senders. Anyone sending more than 5,000 messages a day to Gmail addresses needs SPF, DKIM and DMARC. Since November 2025, Gmail has increasingly rejected non-compliant messages outright. Since May 2025, Microsoft has applied the same requirements to Outlook.com and Hotmail.
An association with a few thousand members reaches that volume with a single circular to all members. Without DMARC, anyone can also send messages with your sender address, such as a fake donation appeal.
Without the records, messages land in spam or get rejected. The guide to association emails going to spam covers other causes.
The three terms
All three are TXT records in your domain’s DNS settings, wherever the domain is registered.
A list of the servers allowed to send messages for your domain. The recipient checks whether the message comes from one of them.
A digital signature in every message. With the public key in DNS, the recipient checks that the message was not altered on the way.
An instruction to the recipient for messages that pass neither SPF nor DKIM aligned with your sender domain. Plus reports on who is sending in your name.
Step by step
The examples use your-association.org. Your mail provider will give you the exact values for SPF and DKIM.
This step is the most important and the one most often skipped. Besides your mailbox provider, the newsletter service, contact form, membership database, donation platform or booking system often send too. Each of these services must later appear in SPF or DKIM.
A single TXT record on the domain itself. Several services are combined with include.
your-association.org. TXT "v=spf1 include:_spf.your-mail-provider.example include:_spf.newsletter-service.example ~all"
Important: only one SPF record per domain, otherwise none is valid. Also no more than ten DNS lookups, so no more than ten include, a, mx and similar terms in total. ~all means “other servers are suspicious”, -all means “other servers are not allowed”. Start with ~all.
Your mail provider generates the key, you only publish the public part in DNS. Each service gets its own name, the selector. Choose 2048 bits if you have the option.
mail2026._domainkey.your-association.org. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"
The DMARC record lives under _dmarc. With p=none delivery stays unchanged, and you receive daily reports from the large providers.
_dmarc.your-association.org. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@your-association.org"
The reports arrive as XML files. A reporting service turns them into a list: which servers sent in your name and whether SPF and DKIM passed.
If your own services fail in the reports, add them to SPF or switch on DKIM there. What counts is alignment: SPF or DKIM must pass for the same domain that appears in the From address. Forwarding often breaks SPF, DKIM usually survives it.
Once all your own services pass, switch to p=quarantine: failing messages go to spam. After a few more weeks without surprises, move to p=reject: they are refused. With pct=25 the new level applies to only part of the traffic at first.
_dmarc.your-association.org. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-association.org"
Every new service that sends in your name needs an entry before it goes live. Read the reports at least once a month.
Checking it works
Send a message to a Gmail mailbox and choose “Show original”. Gmail shows at the top whether SPF, DKIM and DMARC passed. In other programs you will find the same in the Authentication-Results header:
Authentication-Results: mx.google.com;
dkim=pass header.d=your-association.org;
spf=pass smtp.mailfrom=your-association.org;
dmarc=pass (p=REJECT) header.from=your-association.org
If it says pass everywhere, that route is fine. Repeat the test for every service that sends in your name.
If you look after many domains, you need an overview of target and actual values per domain, as secMail’s domain administration shows it. If bounces arrive despite pass, check the blocklists as described in the guide to checking blocklists.
Do it yourself or have it done
For one domain with a mailbox provider and a newsletter service, all you need is access to the DNS settings and a little patience with the reports.
Set it up yourself
Have it done
On our own behalf: we earn money from the second column. If your association has one domain and one mailbox provider, set up the three records yourself with this guide.
Common questions
Not by law. But Google, Yahoo and Microsoft require DMARC from anyone sending more than 5,000 messages a day to their users. Below that, you need at least SPF or DKIM. Regardless, DMARC protects your domain from others sending in your name.
p=none only monitors and sends reports. p=quarantine asks the recipient to put failing messages in spam, p=reject to refuse them. The safe order is none, quarantine, reject, a few weeks apart.
Yes. With more than one SPF record, none is valid and SPF counts as failed. Combine all services into one record with several include terms.
The forwarding server is not listed in your SPF record. DKIM usually survives forwarding as long as the message is not altered. So always set up both.
The records take an hour. Allow four to eight weeks before p=reject, so the reports show every service that sends in your name.
secMail shows the status of MX, SPF, DKIM and DMARC for every domain, even when each branch manages its own domains. Incoming mail is checked against SPF, DKIM and DMARC, and outgoing mail runs through sender classes with their own reputation. We run secMail in German data centres.
Tell us how many domains your organisation has and who sends through them. We will tell you whether you can manage with this guide or secMail is the better fit.
No obligation and no contract. We usually reply within one working day. secMail is priced according to your mail setup, on request.
Prefer to reach us directly? Send an email · call 030 994048000