Email authentication fails in practice when DNS is changed before anyone has identified every system that sends mail for the domain. The result is usually incomplete authorization: a newsletter platform, help desk, CRM, invoice service, or company mailbox may send legitimate mail but not authenticate as expected.
This workflow treats SPF, DKIM, and DMARC as one deployment with three separate checks. SPF identifies authorized sending servers, DKIM adds a verifiable signature to messages, and DMARC checks whether SPF or DKIM aligns with the domain in the visible From address. DMARC also supplies the policy for mail that fails its checks. Valimail
Start with a sender inventory, not a DNS record
Make a list of every system that can send an email using an address at the domain you are configuring. Do not limit the list to the team inbox. Include marketing, transactional email, sales automation, support, forms, billing, recruitment, booking, product notifications, and any server or application that sends mail directly.
For each sender, record the operational details needed to configure it:
- The platform or server name and the internal owner.
- The From domain the recipient sees.
- Whether the system is still actively sending.
- The platform’s SPF instructions, if it supplies an SPF include or server authorization value.
- The DKIM selector, hostname, and record value supplied by the platform.
- Whether the platform has its own domain-authentication screen or documentation.
This inventory is the change-control document for the rest of the setup. SPF records need maintenance when mail is sent through several platforms; Valimail uses Salesforce and Mailchimp as an example of services that need to be included for their legitimate mail to pass SPF checks. Valimail If a service is absent from your inventory, do not assume its DNS value.
Publish SPF from the actual sending inventory
SPF is published in DNS and lets a domain owner define the email servers allowed to send on the domain’s behalf. When a recipient server receives mail, it can compare the sender against that SPF record. Valimail
Open the DNS zone for the sending domain and prepare the SPF value from the sending systems you documented. If mail is sent from a server you operate, use the authorization details appropriate to that server. If delivery is delegated to third-party platforms, obtain their required values from those platforms and add each legitimate provider as instructed. DMARCLY’s setup example likewise distinguishes between a domain’s own sending server and third-party delivery services, and says to list multiple third-party includes separated by spaces in its generator workflow. DMARCLY
Before saving, compare the planned SPF content with the inventory line by line. The practical check is simple: every active sending route has a documented reason to be present, and every listed route has a named owner who can confirm it still sends.
SPF is not a substitute for the other records. It relies on the domain in the Return-Path field, rather than the visible From address that recipients use to judge a message. Valimail That is why the next two stages are required.
Enable DKIM in each sending platform
DKIM adds a digital signature to outgoing mail. A recipient server can verify that signature using the corresponding public key published in the sender domain’s DNS. This verifies message authenticity and integrity, including whether the message has been tampered with in transit. Valimail
For every sender in the inventory, use that platform’s domain-authentication process to generate or retrieve its DKIM DNS instructions. Do not copy a generic DKIM value from another vendor or domain. In its SendGrid example, DMARCLY directs users to create DKIM records in the sending service dashboard and says other providers’ documentation should be used for their own DKIM record creation process. DMARCLY
Publish each required DKIM record exactly at the hostname supplied by its sending platform. Then retain the selector, hostname, platform, and publication date in the inventory. This makes later troubleshooting possible: if a particular platform’s mail fails DKIM, you know which DNS entry and platform configuration to inspect.
Do not treat a published key as proof that every message is signed correctly. DKIM can fail when forwarding services or mailing lists alter headers, even if the original mail was valid. Valimail Test actual messages after DNS verification.
Publish DMARC in monitoring mode with reporting enabled
DMARC ties SPF and DKIM to the visible From domain through alignment and tells receiving servers what to do when authentication does not match. Valimail It has three policy values: p=none, which takes no action; p=quarantine, which sends suspicious mail to spam or junk; and p=reject, which rejects the message. Valimail
Start by generating a DMARC record for the domain with a reporting destination your team can access. Publish it in the DNS zone, then verify that the record is visible. DMARCLY’s documented sequence is to generate the record, publish it, and use a DMARC record checker to confirm that it has taken effect. DMARCLY
A p=none policy is useful as an observation stage, not as the end state. It delivers mail without additional action, while reporting can show whether received mail passed or failed authentication. Valimail Use the reports to compare observed sources against your sender inventory. For each unfamiliar source, classify it as a legitimate system that needs configuration, a retired service that should be removed, or activity you cannot verify.
Run DNS checks and message checks separately
DNS publication and mail authentication are different checks. First, confirm the records can be found in DNS. DMARCLY specifically recommends separate SPF, DKIM, and DMARC record checks after publication. DMARCLY
Second, send a fresh email from each important sending route. Include a company mailbox and every business-critical platform, not just one test sender. DMARCLY documents a test address, check@dmarcly.com, which replies with an authentication-status report including SPF, DKIM, and DMARC. DMARCLY
- Check that the published SPF record is discoverable.
- Check that every provider-issued DKIM record is discoverable.
- Check that the DMARC record is discoverable and contains the intended policy and reporting destination.
- Send a new test message from each material sending system.
- Record the SPF, DKIM, and DMARC result for each test in the sender inventory.
- Investigate failures before changing the DMARC policy.
Move to enforcement only after the sending map is clean
Once reports and message tests account for legitimate senders, choose whether to move from p=none to p=quarantine or p=reject. These policies have explicit handling consequences: quarantine routes the message to spam or junk, while reject prevents delivery. Valimail That makes this a controlled business decision, not merely a DNS edit.
Before changing policy, repeat the inventory review with the people who own marketing, support, sales, finance, and product email. Keep the evidence: DNS checker results, sent-message test results, and DMARC reports. If a sender cannot be verified, leave it unresolved rather than declaring it authorized. A defensible setup is one your team can reproduce: it has a current sender inventory, published records verified in DNS, tests from actual senders, and a DMARC policy selected with known trade-offs.