SoContact

Email deliverability simulator

Check your sending domain's DNS setup for free: SPF, DKIM, DMARC and MX, with a deliverability score and recommendations.

At a glance

Need the 98% verified address? Run the verification in SoContact.

Open in SoContact

Practical guide

Checking SPF, DKIM, DMARC and MX

Understand the need

The DNS check examines public sending-domain records and produces an indicative score. It measures neither domain reputation, message content nor actual inbox placement.

Practical example

A company uses an email provider and wants to check its domain before a campaign. It enters the domain and appropriate DKIM selector. An incorrect selector can hide an existing key; consult the provider’s configuration.

Method and checkpoints

The browser queries a public DNS resolver for SPF, DKIM, DMARC and MX. SPF describes authorized senders, DKIM supports signatures, DMARC specifies an authentication policy and MX identifies receiving servers. Start by defining the question you want to answer and information already available. Use a straightforward case to check your understanding, then add organizational specifics. Compare the result with a known reference where possible. Missing information should be distinguished from a negative result, and an estimate should not be presented as a measurement. Record parameters and limitations so a colleague can reproduce the reasoning without interpreting the outcome differently. If assumptions change, perform a new assessment rather than comparing results produced under incompatible conditions.

Limits and decision criteria

A missing result can reflect an actual absence, incorrect selector or temporary lookup issue. Check with the provider before changing configuration. Publishing a strict policy without testing legitimate flows can block expected messages. Before using the outcome to decide, verify its scope. Campaign preparation includes independent steps: targeting, contact quality, messaging, technical configuration and follow-up. No isolated indicator guarantees overall success. Relate this page’s information to your team’s actual context. Do not collect additional personal data without a clear purpose. Examples are educational and animations use fictional profiles. For account conditions, offers or available capabilities, always confirm information in the SoContact application before committing. Consider who will act on the result and what checks are required before that action can safely proceed.

Prepare the next step

Continue with the section answering the next need instead of repeating the same test without changing your hypothesis. Suggested links connect preparation, research and comparison. This progression helps interpret outcomes, identify missing checks and choose a concrete action rather than stopping at a score or list. Keep observations available for later review. For “Checking SPF, DKIM, DMARC and MX”, also ask which observations would confirm or challenge your initial hypothesis. This connects preparation with a verifiable decision and prevents generalizing results beyond their context. Review findings with the people involved before changing your process, and distinguish measured improvements from assumptions that still require evidence. Keep the evaluation transparent, specific and reproducible for every stakeholder involved. A documented review makes comparisons easier and preserves assumptions when requirements change. Use relevant observations rather than generic promises to support the decision.

Official references: DMARC · RFC 7489

Frequently asked questions

Understand the need — What should be understood?

The DNS check examines public sending-domain records and produces an indicative score. It measures neither domain reputation, message content nor actual inbox placement. A company uses an email provider and wants to check its domain before a campaign. It enters the domain and appropriate DKIM selector. An incorrect selector can hide an existing key; consult the provider’s configuration.

Practical example — What should be understood?

A company uses an email provider and wants to check its domain before a campaign. It enters the domain and appropriate DKIM selector. An incorrect selector can hide an existing key; consult the provider’s configuration.

Method and checkpoints — What should be understood?

The browser queries a public DNS resolver for SPF, DKIM, DMARC and MX. SPF describes authorized senders, DKIM supports signatures, DMARC specifies an authentication policy and MX identifies receiving servers. Start by defining the question you want to answer and information already available.

Limits and decision criteria — What should be understood?

A missing result can reflect an actual absence, incorrect selector or temporary lookup issue. Check with the provider before changing configuration. Publishing a strict policy without testing legitimate flows can block expected messages. Before using the outcome to decide, verify its scope.

Prepare the next step — What should be understood?

Continue with the section answering the next need instead of repeating the same test without changing your hypothesis. Suggested links connect preparation, research and comparison. This progression helps interpret outcomes, identify missing checks and choose a concrete action rather than stopping at a score or list.

Understand the need — What should be checked?

The DNS check examines public sending-domain records and produces an indicative score. It measures neither domain reputation, message content nor actual inbox placement. A company uses an email provider and wants to check its domain before a campaign. It enters the domain and appropriate DKIM selector. An incorrect selector can hide an existing key; consult the provider’s configuration.

Practical example — What should be checked?

A company uses an email provider and wants to check its domain before a campaign. It enters the domain and appropriate DKIM selector. An incorrect selector can hide an existing key; consult the provider’s configuration.