Short answer: Three entries, three tasks
Which servers can send for your domain?
Has the message been changed on the way?
What happens if there is a lack of authentication?
The three methods are not a guarantee of incoming mail. They prove that an email comes from an authorized sender and was not changed along the way. Reputation, content and recipient feedback continue to be a deciding factor.
1. Why email authentication is important
Without authentication, anyone can spoof your domain name in the sender. This is abused for phishing, invoice fraud and spam - and damages your domain reputation in the long term. Large mail providers are increasingly requiring SPF, DKIM and DMARC to send to their users. Anyone who sends newsletters, invoices or system emails should not leave the entries to chance.
The distinction is important: authentication is not a spam filter and not an encryption. It answers the question “Can these servers send this mail on behalf of this domain?” – not “Is this mail desired or secure?”.
2. SPF: Who can send?
SPF (Sender Policy Framework) is a DNS TXT record. It lists the servers and services that are allowed to send for your domain. A recipient compares the IP address of the sending server with this list.
example.at. TXT "v=spf1 include:_spf.example.net -all"Wichtig: There is only one SPF record per domain. Multiple SPF records lead to a PermError. The record also has a limit of ten DNS lookups; many includes can exceed this limit. And: SPF checks the envelope sender (return path), not automatically the visible from address.
3. DKIM: Is the email unchanged?
DKIM (DomainKeys Identified Mail) signs the message with a private key. The appropriate public key is in a DNS entry under a selector. The recipient can use this to check whether the signed headers and content were changed along the way.
selector._domainkey.example.at. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."The private key remains on the mail server or with the shipping service. Never publish the private key in DNS. Some DNS providers have length limits for 2048-bit keys; then the entry must be split or another selector used. Rotate keys regularly and document which service uses which selector.
4. DMARC: What happens if an error occurs?
DMARC (Domain-based Message Authentication, Reporting and Conformance) combines SPF and DKIM. It checks whether the visible from domain matches the authenticated domain (alignment) and sets a policy.
_dmarc.example.at. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"- ✓ p=none: only observe, no change of delivery.
- ✓ p=quarantine: Move suspicious mails into quarantine/spam.
- ✓ p=reject: unauthentifizierte Mails ablehnen.
- ✓ rua: Send aggregated reports to an email address.
- ✓ adkim/aspf: Strict or loose alignment.
Starte mit p=none und werte die Reports aus. Erst wenn alle legitimen
Versandwege erkannt und authentifiziert sind, solltest du auf quarantine und später
reject wechseln. Ein sofortiges reject kann Newsletter, Weiterleitungen oder
Systemmails abbrechen.
5. The interaction – and an example
Eine typische Prüfung läuft so: Der Empfänger sieht eine Mail von [email protected].
SPF prüft die IP des sendenden Servers, DKIM prüft die Signatur, DMARC vergleicht die
authentifizierte Domain mit der sichtbaren From-Domain und wendet die Policy an.
| Entry | Zweck | Typical mistake |
|---|---|---|
| SPF | Authorized sender IPs | Two SPF records or lookup limit exceeded |
| DKIM | Signature and integrity | Incorrect selector or expired key |
| DMARC | Alignment and policy | Too early on reject, reports not evaluated |
Die Beispiele sind Platzhalter. Kopiere keine fremden Werte und teste Änderungen zuerst
mit einer kleinen Teilmenge (pct) und aussagekräftigen Reports.
6. Typical mistakes
Only one SPF TXT entry per domain; Merge includes cleanly.
SPF/DKIM must match the visible from domain, not just be valid somewhere.
SPF breaks on some redirects; DKIM often remains more stable.
Newsletters, CRM, shops and time recording often send via their own services.
Without a rua address, DMARC remains a blind flight.
First observe, then quarantine, then reject – not the other way around.
7. Archiving, migration and operations
Authentication is just one part of a clean email infrastructure. This includes mailboxes, aliases, spam filters, TLS and a documented offboarding process. During a migration, mailboxes, calendars and contacts are taken over, MX and DNS entries are checked and the changeover is accompanied.
Archiving is more than just storing old emails: it requires defined retention periods, export and recovery paths, and clear responsibilities. Whether and for how long you have to keep emails depends on the industry and legal form - this is not legal advice. We set up the technical archiving according to your specifications and document the process.
8. Setup checklist
The checkboxes are a reminder, not a saved status.
Questions about SPF, DKIM and DMARC
SPF is a DNS list of servers that are allowed to broadcast for your domain. DKIM cryptographically signs every email so that recipients can see whether the message has been altered. DMARC combines both methods, checks whether it matches your domain and determines what should happen to unauthenticated emails.
No. SPF only checks the envelope sender and can break with redirects or complex delivery routes. For reliable results, you need SPF, DKIM and DMARC together - and a regular evaluation of the DMARC reports.
p=none is the observation level: DMARC checks authentication, but does not quarantine or reject any mail, and is the right start for getting to know senders, reports and misconfigurations, and only then should you switch to quarantine or reject.
Authentication only proves that an email comes from an authorized sender. It says nothing about content, reputation, complaints, blocklists, shipping volume or recipient feedback. Spam filters, attachments, links and a young domain can also influence delivery.
That's risky. If unknown shipping channels, newsletter tools or redirects still exist, legitimate emails can be lost. The usual way is: p=none, evaluate reports, record all legitimate senders, then gradually quarantine and later reject.
No. The three methods authenticate the sender and the integrity of the message, they do not encrypt it. Transport encryption runs over TLS between the mail servers. For end-to-end confidentiality, you also need end-to-end encryption.
This depends on the number of domains, mailboxes and shipping routes. With a manageable configuration, the effort is often small; For multiple systems, migrations or archiving, the costs are calculated individually. After a short check, you will receive a fixed price for the agreed scope.