Email security
Domain check
Could someone send emails in your company’s name? The check reads the public DNS records of your domain and shows how well SPF, DKIM and DMARC protect you, and what is missing.
Why it matters
Many fraud attempts start with a forged sender: the supposed managing director who needs an urgent transfer, or the supplier with a new bank account. In August 2026, CERT.at warned of an increase in such cases (business email compromise) and recommends introducing SPF, DKIM and DMARC and setting DMARC to “reject” for an organisation’s own domains.
The large mailbox providers require these records too. Google, for example, has expected SPF or DKIM from all senders since February 2024, and SPF, DKIM and DMARC from those sending more than 5,000 emails a day to Gmail addresses. Germany’s BSI has set out auditable requirements for email service providers in its Technical Guideline TR-03182.
- CERT.at: increased fraud attempts through BEC (26 Aug 2026)
- Google: email sender guidelines
- BSI TR-03182 Email Authentication
What the records mean
SPF: who may send
A TXT record lists all servers that may send emails for your domain, such as your email system, the newsletter tool and the ticket system. Recipients compare the sending server with this list. Each domain may have only one SPF record, and it may trigger at most ten further DNS lookups.
DKIM: the digital signature
Your email system signs every outgoing email. You publish the matching public key in the DNS under a selector, for example selector1._domainkey. Recipients can see that the email comes from your system and was not changed on the way. RSA keys with at least 2,048 bits are recommended.
DMARC: what happens to forgeries
DMARC ties SPF and DKIM to the sender address that recipients see and defines what happens to emails that fail: nothing (none), the spam folder (quarantine) or rejection (reject). Reports (rua) show you who sends in your name. The current standard is RFC 9989 from 2026, which replaces RFC 7489.
Domains without email
Domains you never send emails from are used for forgeries too. The UK’s National Cyber Security Centre recommends four records for them: “v=spf1 -all”, “v=DMARC1; p=reject”, a null MX and an empty DKIM key for all selectors.
MTA-STS and TLS-RPT: the way to you
With MTA-STS you require sending servers to deliver only encrypted and only to your genuine mail servers. TLS-RPT sends you reports when that fails. Both are optional.
CAA: who may issue certificates
A CAA record defines which certificate authorities may issue TLS certificates for your domain. This makes forged certificates for your website harder. CAA has nothing to do with email, but it is quick to set up.
What the check does not test
- whether your mail servers themselves are configured securely, such as TLS versions and certificates
- DNSSEC and DANE
- the MTA-STS policy file
- DKIM keys under selectors we do not know (enter your selector above)
- whether your domain or servers are on blocklists
A comprehensive test, including the mail servers, is offered by internet.nl, for example.
The check is a snapshot of the public DNS records and does not replace a security assessment. Changed records only become visible everywhere once their cache lifetime (TTL) has expired.
Want to secure your domain properly?
Before DMARC rejects forgeries, every genuine sender has to be covered, from the newsletter tool to the accounting software. We work through it with you step by step.
Your contacts: Christian, Tobias and Michael, the founders of AmberTech Solutions.