Check SPF, DKIM and DMARC for each sending route
Check your application’s actual email route. A constructed example separates DNS authorisation, signatures and alignment with the sender domain.
When an application sends email through an external service, looking at the company address in the mail client is not enough. Record the actual sending route and check an approved test message at the intended receiving point. DNS records and message checks answer different questions.
Start with a specific sending route
In the fictional design, a customer portal sends status notifications. The visible sender is hinweis@firma.example; the external service uses versand.example as the domain for its SMTP sender and signature. These names serve only this design. No message was sent and no DNS record was queried.
First establish which application triggers the email, which service carries it and who manages that service’s domain configuration. Record other routes separately, such as notifications from a support system. One service’s configuration does not establish another’s.
Check DNS and the actual message together
SPF describes authorised servers for SMTP identities. Match the published record to the SMTP domain actually used. The presence of a TXT record alone is not a successful result for the specific sending route.
DKIM associates signed message components with the signing domain. Also check whether the sending service actually signs and whether the signature is valid at the intended receiving point. Publishing a public key in DNS does not establish that on its own. Account for services that process the message after signing.
DMARC requires a successful SPF or DKIM check with appropriate domain alignment to the visible sender. This relationship is called alignment. Determine the applicable DMARC record and the alignment conditions it specifies as well.
Assess an individual positive result correctly
The following table contains deliberately constructed assumptions for the same design, not measured results.
Check | Assumed finding | Significance for approval |
|---|---|---|
SPF | The sending server is authorised for the service’s SMTP domain. | Establishes that domain authorisation, not the visible company address. |
DKIM | The message carries a valid signature from the service’s domain. | Establishes that signature, not the required alignment. |
DMARC | An applicable record exists; neither the SPF nor the DKIM domain aligns appropriately with the visible sender domain. | Under these assumptions, the two positive individual findings do not produce a successful DMARC result. |
For approval, the specific service must support suitable domain configuration and the associated sending behaviour. The required change depends on the service. Copying an arbitrary existing DNS record or hastily setting a policy to rejection does not solve the alignment problem.
Record the controlled sending test as evidence
Document the sending route, domains used, checked message and results for the test. If further services process the message, that route also needs a suitable test case. Repeat the check after changes to the service, domain or message processing.
Google treats authentication as part of its sender requirements. Even a successful technical test case establishes neither inbox placement nor reading. Record receipt observations separately and identify who handles failed checks and delivery feedback.
Sources
Read more
All articles
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.