When an email fails or lands in spam, the issue often lies elsewhere. In many cases, it relates to the configuration of the sending domain.
SPF, DKIM and DMARC follow this logic and rely on DNS records to help mail systems distinguish legitimate email from potentially fraudulent traffic.
Anyone who manages domains, email services or IT infrastructures often needs to verify these records. This need typically emerges during a migration, after enabling a new sending service or when delivery issues keep recurring.For an initial check, you do not need advanced tools or proprietary platforms. You can query the DNS directly and verify what a domain actually publishes.
SPF, DKIM and DMARC cover different aspects of email authentication, but they work closely together. SPF defines which servers can send email on behalf of a domain. DKIM signs outgoing messages so that the receiving server can verify their integrity. DMARC defines how receiving servers should behave when SPF or DKIM checks fail and provides useful data to monitor email traffic.
When one of these elements is missing or inconsistent, mail servers start treating messages with greater suspicion, with a direct impact on delivery. For this reason, checking DNS records often represents the first step in identifying the source of a problem.
To verify SPF, DKIM and DMARC, you can use standard commands such as dig or nslookup, which are available on most operating systems. These tools let you query the DNS directly and see exactly which records a domain publishes, without intermediaries or assumptions. This approach proves particularly useful when you analyze issues reported by a customer or when you want to assess a domain before an email migration.
The SPF record lives inside the domain’s TXT records. When you query the DNS, you receive one or more text strings, including the one that starts with v=spf1, which lists the servers authorized to send email.
If a sending server does not appear in this list, the messages it generates risk rejection or classification as suspicious. This scenario becomes especially relevant when a domain relies on multiple sending services, for example an Email Hosting service alongside an SMTP relay for transactional messages.
DKIM relies on a selector to identify the public key associated with outgoing message signatures. The domain publishes this record in the DNS under a name that combines the selector with _domainkey.
To verify the presence of the record, you need to access the DNS management panel for the domain and check whether a TXT record exists under selector._domainkey.example.com.
When the record exists and matches the configuration of the sending server, the receiving server can verify the DKIM signature correctly. When the record is missing or inconsistent, the verification fails, even if the sending server signs messages properly.
You find the DMARC record under the name _dmarc followed by the domain, again as a TXT record. In this case, the focus shifts to the actions that receiving servers should take when SPF or DKIM checks fail.
DMARC lets administrators define how receivers should handle these messages and receive reports that help identify who sends email for the domain and with what results. A clear DMARC policy reduces ambiguity and simplifies the analysis of deliverability issues. DMARC also lets you specify the email address that should receive these reports, providing direct visibility into authentication outcomes.
Verifying SPF, DKIM and DMARC proves useful in many operational scenarios, from daily domain management to resolving issues reported by customers. Direct visibility into DNS records helps teams identify incomplete or inconsistent configurations quickly, without relying on trial and error.
A correct DNS configuration improves the reliability of an email service, reduces the number of reported issues and simplifies the work of technical support teams.
Checking SPF, DKIM and DMARC offers a solid starting point, but it does not always guarantee that the configuration aligns with the sending service in use or with the actual needs of the domain. Records may exist but remain incomplete, redundant or poorly structured, especially when multiple sending services or providers accumulate over time.
In these cases, taking an additional step and reviewing how these records interact helps prevent delivery issues and reduce reports. In this in-depth guide, you can find a clear overview of SPF, DKIM and DMARC and their role in the correct management of a domain’s email