Email Authentication Records: Set Up SPF, DKIM, and DMARC Correctly

Email authentication records are DNS records that prove which services can send mail for your domain, cryptographically sign your messages, and tell receiving mail systems how to handle spoofed mail. For any business that sends email—from a mailbox provider, marketing platform, help desk, CRM, or transactional-email service—SPF, DKIM, and DMARC are foundational infrastructure, not optional deliverability polish.

What are email authentication records?

Email authentication records are DNS entries that receiving mail servers query when they evaluate a message claiming to come from your domain. The three records that matter most are:

• SPF (Sender Policy Framework): identifies the servers authorized to send mail using a domain in the SMTP envelope sender.
• DKIM (DomainKeys Identified Mail): publishes a public key used to verify a cryptographic signature added to an outgoing email.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): checks whether SPF or DKIM passed and aligns with the visible From: domain; it also publishes a requested handling policy and reporting destination.

These mechanisms solve related but different problems. SPF answers, “Was this sending server authorized for the envelope domain?” DKIM answers, “Did an authorized domain sign this message, and has the signed content survived transit?” DMARC answers, “Does an authenticated identifier correspond to the domain the recipient sees in the From: field?”

All three are published in DNS, but they are not interchangeable. A domain with only SPF can still have messages that fail DMARC. A domain with valid DKIM signatures can still fail DMARC if the signing domain does not align with the visible sender domain. A DMARC record without working SPF or DKIM gives you a policy and reports, but not the authenticated mail streams required to make that policy safe.

Google’s sender rules require every sender to personal Gmail accounts to use SPF or DKIM, while senders that send more than 5,000 messages per day to personal Gmail accounts need SPF, DKIM, and DMARC. Yahoo also treats SPF, DKIM, and DMARC as essential sender practices. That makes authentication a practical requirement even for organizations whose main goal is simply reliable delivery rather than anti-phishing enforcement.

The three records and how they work together

A useful way to understand email authentication records is to follow one email through its journey.

Suppose northstarcoffee.com sends a receipt from receipts@northstarcoffee.com through a transactional platform. The recipient sees this visible header:

From: Northstar Coffee <receipts@northstarcoffee.com>

Behind the scenes, SMTP also has an envelope sender, sometimes called MAIL FROM, Return-Path, or bounce domain. It might be:

MAIL FROM:<bounce@mailer.northstarcoffee.com>

The sending platform may add a DKIM signature such as:

DKIM-Signature: v=1; a=rsa-sha256; d=northstarcoffee.com;
 s=tx2025; ...

When the receiving server gets the message, it can perform these checks:

1. SPF: Is the IP address that delivered the mail allowed by the SPF record for mailer.northstarcoffee.com?
2. DKIM: Does the signature verify using the public key published at tx2025._domainkey.northstarcoffee.com?
3. DMARC: Did SPF pass with an aligned envelope domain, or did DKIM pass with an aligned d= signing domain, relative to northstarcoffee.com in the visible From: field?

DMARC passes if at least one of SPF or DKIM both passes authentication and aligns with the visible From: domain. It does not require both mechanisms to align on every individual message. Operationally, however, configuring both is safer because forwarding and mailing-list changes can break SPF, while later message modifications can break DKIM.

Authentication is not an inbox-placement guarantee

Correct records establish domain identity and prevent certain kinds of spoofing. They do not guarantee inbox placement. Mail providers also evaluate reputation, user complaints, content, engagement, sending patterns, IP and domain history, malware indicators, and other abuse signals.

That distinction matters. If a properly authenticated campaign lands in spam, do not “fix” it by weakening DMARC. Investigate list quality, subscription practices, message content, complaint rate, sending volume changes, and the reputation of the sending domain or IP. Authentication is a baseline that makes legitimate mail easier to evaluate; it is not a bypass for spam filtering.

Before creating records: inventory every sender

The most common implementation mistake is publishing records before identifying every system that sends mail as your domain. The result is predictable: a new DMARC policy blocks real mail from a forgotten application, vendor, office device, or team.

Build an inventory before changing DNS. Include every system that can generate mail with your domain in the visible From: field, envelope sender, or DKIM signing domain.

Typical senders include:

• Google Workspace, Microsoft 365, or another mailbox provider
• Marketing platforms such as Mailchimp, HubSpot, Klaviyo, Braze, or Customer.io
• Transactional providers such as Amazon SES, Postmark, SendGrid, Mailgun, Resend, or SparkPost
• Support systems such as Zendesk, Intercom, Freshdesk, or Help Scout
• CRM, invoicing, accounting, and recruiting software
• Website forms, WordPress plugins, ecommerce systems, and server-side applications
• Internal tools, CI/CD notifications, printers, scanners, and monitoring platforms
• Agencies or subsidiaries sending on your behalf

For each sender, record four things:

Do not assume a vendor listed in your SPF record is correctly authenticated. An include: mechanism may authorize its sending infrastructure for SPF, but the vendor could still use an unaligned return-path domain, or your configuration might not actually route mail through the expected authenticated domain.

Use real message headers to find unknown senders

A mailbox’s “show original,” “view source,” or “view message headers” feature is one of the fastest discovery tools. Send representative messages from each business system to a test inbox, then inspect:

• From: for the visible author domain
• Return-Path: for the envelope sender domain
• DKIM-Signature: for the d= signing domain and s= selector
• Authentication-Results: for the recipient’s SPF, DKIM, and DMARC verdicts
• Received: lines for clues about the service that transmitted the message

Microsoft 365 adds an Authentication-Results header for received messages that includes SPF, DKIM, DMARC, and composite-authentication results. Gmail likewise exposes authentication results in message details and original message source. These headers show what a receiving system actually observed, which is more useful than assuming a DNS record should work.

How to create an SPF record

An SPF record is a DNS TXT record at the domain used in the SMTP envelope sender. Its value begins with v=spf1 and contains mechanisms that authorize senders, followed by a final policy qualifier.

A simple SPF record for a domain that sends only through Google Workspace is commonly structured like this:

Host/Name: @
Type: TXT
Value: v=spf1 include:_spf.google.com ~all

The exact vendor include value is vendor-specific. Use the provider’s current documentation rather than copying an include from an old blog post. For example, Google Workspace documents _spf.google.com for its standard SPF configuration, while Microsoft 365 and email platforms provide different authorization mechanisms.

Read SPF syntax from left to right

Consider this example:

v=spf1 include:_spf.google.com include:spf.mtasv.net ip4:198.51.100.24 -all

It means:

• v=spf1 — this is an SPF version 1 policy.
• include:_spf.google.com — authorize the sending infrastructure permitted by Google’s SPF record.
• include:spf.mtasv.net — authorize a second provider, if that provider specifically instructed you to use this include.
• ip4:198.51.100.24 — authorize one IPv4 sending address.
• -all — fail all other senders.

The four common qualifier outcomes are:

• + pass, normally implicit when no qualifier is present
• - fail
• ~ softfail
• ? neutral

For a completed, accurately inventoried configuration, -all expresses the clearest authorization boundary. During a discovery phase, teams sometimes publish ~all temporarily to reduce the immediate impact of an overlooked sender. Neither choice repairs a missing sender; it only changes the SPF result. The durable fix is to authorize legitimate sources correctly or stop them from sending as your domain.

SPF has a DNS-lookup limit

SPF evaluation has a limit of 10 DNS-querying mechanisms or modifiers. include, a, mx, exists, redirect, and some forms of ptr can consume the lookup budget; nested includes can consume more than one lookup. Exceeding the limit produces an SPF permerror, which can cause downstream authentication problems.

This is why an SPF record becomes fragile when every department adds another vendor include. Do not create multiple SPF TXT records to work around the limit. SPF permits one record for a domain; multiple records can cause a permanent error. Consolidate all legitimate mechanisms into one logical SPF record, remove obsolete providers, use a dedicated subdomain for a particular platform where appropriate, or configure a vendor’s custom bounce domain and DKIM instead of endlessly expanding the organizational domain’s SPF policy.

SPF pitfalls that cause avoidable failures

The biggest SPF errors are operational, not syntactic:

1. Multiple SPF records. A domain should publish one SPF policy record, not one TXT record per sender.
2. Missing a sender. A forgotten form plugin or billing system sends from your domain but is not authorized.
3. Using the wrong domain. SPF is evaluated against the envelope domain, which can differ from the visible From: domain.
4. Exceeding 10 DNS lookups. The record looks plausible but yields permerror at receivers.
5. Leaving old includes indefinitely. Former vendors remain authorized to send mail for your domain.
6. Assuming SPF survives forwarding. A forwarding server’s IP is often not in the original sender’s SPF record, so SPF failure after forwarding is expected.

The final point explains why SPF alone is insufficient. DKIM can survive ordinary forwarding because the recipient verifies a signature using DNS rather than the forwarding server’s IP address, provided the forwarded message has not been altered in a way that invalidates the signature.

How to create a DKIM record

DKIM uses public-key cryptography. Your email service holds a private key and uses it to sign outgoing messages. DNS publishes the matching public key. The recipient retrieves that key and verifies the message signature.

The DKIM DNS name follows this pattern:

selector._domainkey.example.com

A selector is a label chosen by the sending system, such as google, s1, k1, mail, or a vendor-generated identifier. It lets a domain use multiple keys at once and rotate keys without interrupting delivery.

DKIM TXT-record example

Some platforms ask you to publish a TXT key directly. The record resembles this:

Host/Name: tx2025._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The string after p= is a public key. Do not invent, edit, truncate, or substitute it. Copy the value generated by the sending provider exactly. DNS dashboards may visually split a long TXT string into quoted chunks; that is normally fine when the DNS provider treats the chunks as one logical TXT value.

Other services, especially hosted mailbox providers and email platforms, use CNAME delegation instead. For example, a provider may ask for records shaped like:

selector1._domainkey.example.com CNAME selector1-example-com.vendor-domain.example
selector2._domainkey.example.com CNAME selector2-example-com.vendor-domain.example

In that model, the provider hosts the ultimate DKIM key and can rotate it. Follow the provider’s exact hostnames and targets. Do not replace a required CNAME with a TXT record, and do not publish both at the same selector name.

DKIM alignment is the deliverability detail people miss

A DKIM signature can pass cryptographic verification yet fail DMARC. The reason is alignment.

For this visible address:

From: announcements@northstarcoffee.com

A signature with this domain is aligned under normal relaxed alignment rules:

d=northstarcoffee.com

This may also align under relaxed alignment:

d=mailer.northstarcoffee.com

But this normally does not align:

d=email-vendor.example

The third signature can prove that the vendor signed the message, but it does not prove that northstarcoffee.com authorized the visible sender in the way DMARC requires. The practical solution is to complete the vendor’s “domain authentication,” “branded sending domain,” or “custom DKIM domain” setup so it signs as your domain or an aligned subdomain.

DKIM key and operational practices

Use the provider’s supported modern key configuration. DKIM supports RSA keys and also has a standards-defined Ed25519-SHA256 signing algorithm. Compatibility varies by sending provider and recipient implementation, so do not select an algorithm based solely on a theoretical preference; use what your mail platform supports and documents.

Keep at least one working selector live during any rotation. A safe rotation sequence is:

1. Publish the new selector’s DNS record.
2. Wait until the record resolves from public DNS.
3. Configure the sender to sign with the new selector.
4. Send test messages and verify dkim=pass.
5. Leave the old key published until mail signed with it has aged out of normal delivery and retry windows.
6. Remove the old record only after verification.

Do not delete a DKIM record simply because you have generated another one. Messages delayed in queues or retried later may still need the old public key to validate.

How to create a DMARC record

DMARC is a DNS TXT record published at _dmarc.yourdomain.com. It tells receivers how to evaluate messages using the visible From: domain, what policy the domain owner requests for failures, and where aggregate reports may be sent.

A sensible monitoring-first DMARC record looks like this:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarcoffee.com

This says:

• v=DMARC1 — DMARC record version.
• p=none — request monitoring rather than a failure-enforcement action.
• rua=mailto:... — request aggregate reports at the specified mailbox.

A more mature enforcement record could look like:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@northstarcoffee.com; adkim=r; aspf=r

Or, when all legitimate streams are confirmed:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@northstarcoffee.com; adkim=r; aspf=r

The p tag has three core policy values:

DMARC expresses a domain owner’s requested policy; receiving systems make their own final delivery decisions. Therefore, a p=reject policy is powerful but not a license to skip testing, and a p=none policy is visible monitoring rather than spoofing enforcement.

Relaxed versus strict alignment

The adkim and aspf tags control alignment mode:

adkim=r; aspf=r

r means relaxed alignment. A related subdomain can align with the organizational domain, such as mailer.northstarcoffee.com relative to northstarcoffee.com.

adkim=s; aspf=s

s means strict alignment. The authenticated domain must exactly match the visible From: domain. Strict alignment can be appropriate for tightly controlled environments, but it can break legitimate vendor and subdomain configurations. Start by understanding actual authenticated identifiers in your mail headers before choosing strict alignment.

DMARC reports are your migration map

Aggregate DMARC reports are typically machine-readable XML files, often compressed, sent by participating receivers to the address in rua. They summarize observed sending IPs, message counts, SPF and DKIM results, aligned-domain results, and policy decisions.

Reports answer questions DNS cannot answer alone:

• Which IP addresses are sending mail claiming to be from your domain?
• Which sources pass DKIM but fail SPF because of forwarding?
• Which third-party service is using an unaligned signing domain?
• Is a deprecated platform still sending mail?
• Is someone attempting to impersonate your domain?

A dedicated reporting mailbox is better than an employee inbox. High-volume domains can receive many compressed XML attachments. Teams that do not want to parse XML manually can use DMARC-reporting products or ingest reports into their own analytics workflow, but the underlying decision remains the same: identify every legitimate source before increasing policy enforcement.

Worked example: authenticate a small business domain

Assume brightpathstudio.com has these legitimate mail streams:

• Google Workspace for employee mail
• A marketing platform for newsletters
• A transactional provider for website receipts
• A help desk that sends support replies

The goal is to authenticate all streams without breaking customer email.

Step 1: decide which domain each system should use

Use the organizational domain for employee mail:

hello@brightpathstudio.com

Use a subdomain for marketing if the platform supports it:

news@updates.brightpathstudio.com

Use another subdomain for transactional mail if appropriate:

receipts@mail.brightpathstudio.com

This subdomain approach is not mandatory, but it can reduce operational coupling. Marketing changes, reputation events, vendor migrations, and SPF complexity on a high-volume stream are less likely to affect everyday employee email. The visible From: address must still be intentional and the relevant domains need aligned SPF or DKIM.

Step 2: publish one SPF policy for the root domain

If Google Workspace is the only service using an envelope sender at brightpathstudio.com, its SPF record can be:

brightpathstudio.com. TXT "v=spf1 include:_spf.google.com -all"

Do not also publish another record like this:

brightpathstudio.com. TXT "v=spf1 include:vendor.example -all"

Two SPF records do not mean “Google plus vendor.” They create an invalid SPF situation. If a second service truly needs the root domain’s envelope sender, merge the authorized mechanisms into one record after checking the combined DNS lookup count. Prefer a vendor-managed custom return-path subdomain when the vendor offers one.

Step 3: configure DKIM in every sending platform

In Google Workspace, generate and enable the provider’s DKIM configuration for brightpathstudio.com, then publish the supplied DNS record. For the marketing, transactional, and help-desk providers, complete each provider’s domain-authentication workflow.

That workflow may request two or three CNAME records for DKIM, a custom bounce-domain CNAME, or a TXT key. Do not generalize the exact records across providers. Copy the values each platform generates for brightpathstudio.com, updates.brightpathstudio.com, or mail.brightpathstudio.com as applicable.

Step 4: publish monitoring DMARC

For the parent domain:

_dmarc.brightpathstudio.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@brightpathstudio.com; adkim=r; aspf=r"

For a subdomain that has its own sending program, publish a dedicated policy if you need separate control and reporting. Otherwise, understand how your parent-domain policy applies to subdomains and confirm what the sender uses in its visible From: address.

Step 5: send controlled tests

Send one message from each sender to personal Gmail and Microsoft 365 test inboxes. Open message source and look for results similar to:

spf=pass
dkim=pass
dmarc=pass

Then check the domains associated with the results. A raw “pass” is not enough if DMARC fails. You want either:

header.d=brightpathstudio.com

or an aligned subdomain such as:

header.d=mail.brightpathstudio.com

You also want the visible From: field to match the intended business identity. A receipt sent from receipts@mail.brightpathstudio.com that signs with d=mail.brightpathstudio.com is a straightforward aligned design.

Step 6: review reports before enforcement

Review DMARC aggregate reports over a representative business cycle. Include monthly invoicing, support responses, campaign sends, password resets, recruiting notices, and any seasonal or automated workflows. For each source that fails DMARC, determine whether it is legitimate, misconfigured, obsolete, or malicious.

Only after legitimate mail consistently passes should you move from p=none to p=quarantine, and eventually consider p=reject. Keep monitoring after every policy change. Authentication is an ongoing ownership process because vendors, domains, teams, and mail streams change.

How to validate email authentication records

There are two separate validation tasks: DNS validation and message validation.

Validate the DNS records

Use a DNS lookup tool, your DNS provider’s record viewer, or command-line utilities such as dig.

Examples:

dig TXT brightpathstudio.com +short
dig TXT tx2025._domainkey.brightpathstudio.com +short
dig TXT _dmarc.brightpathstudio.com +short

You are checking that:

• the record exists publicly;
• the hostname is correct;
• the TXT value is complete;
• you have one SPF policy at the relevant domain;
• DKIM selectors resolve as the sender expects;
• the DMARC record is at _dmarc, not at the root domain;
• CNAME targets resolve if the provider uses CNAME delegation.

DNS propagation behavior depends on the record’s TTL and resolver caches. A control panel showing a record immediately does not prove that every receiving resolver can see it yet. Verify from public DNS after publishing and before enabling a provider feature that depends on the record.

Validate an actual message

DNS alone does not prove that your sender is using the records. Send a test email through each system and inspect the recipient’s message headers.

Look for an authentication summary such as:

Authentication-Results: ...;
 spf=pass ...;
 dkim=pass header.d=brightpathstudio.com;
 dmarc=pass header.from=brightpathstudio.com

Interpret failures precisely:

• spf=fail: The sending IP is not authorized for the envelope domain, or SPF could not be evaluated correctly.
• spf=permerror: Often indicates multiple SPF records, malformed syntax, or too many DNS lookups.
• dkim=fail: The public key is missing or incorrect, the wrong selector is published, the service is not signing, or signed content was altered.
• dmarc=fail while SPF/DKIM passes: Usually an alignment issue. Check the visible From: domain against SPF’s authenticated envelope domain and DKIM’s d= domain.
• dmarc=pass but mail is in spam: Authentication works; investigate reputation, content, consent, complaints, and list quality.

Google Postmaster Tools can provide eligible senders with information about spam rate, reputation, authentication, and delivery errors for mail sent to personal Gmail accounts. It is a useful operational complement to DMARC reports, especially for teams sending meaningful volume to Gmail users.

Common problems and the fixes that actually work

“I added SPF, but DMARC still fails”

SPF may have passed for a domain unrelated to the visible From: domain. For example, SPF can pass for mail.vendor.example, while the visible sender is billing@brightpathstudio.com. That is not aligned SPF for DMARC.

Fix it by configuring a custom return-path or bounce domain under your domain, or by enabling aligned DKIM signing through the vendor. The latter is often the cleaner answer because DKIM is less sensitive to ordinary forwarding.

“Our marketing platform says DKIM is verified, but recipients see failure”

Check the selector and record type. A platform may have generated s1._domainkey but you published s2._domainkey, or it may require CNAME records while you published a TXT record. Also confirm that the provider has actually enabled the authenticated domain for the relevant sending stream rather than only verifying ownership in its dashboard.

Use a fresh test email and inspect the DKIM-Signature header. The s= value tells you exactly which selector the recipient queried; the d= value tells you the signing domain the sender actually used.

“We moved to p=reject and legitimate mail disappeared”

Revert only as far as necessary to restore critical mail, then use headers and DMARC reports to identify the missing source. Typical culprits are automated applications, help-desk forwarding, campaign tools used by another team, devices using direct SMTP, and partners who were permitted to use your domain informally.

Do not solve this by authorizing every unknown IP or leaving a broad, permanent exception. Either configure the source to use aligned DKIM or SPF, move it to a purpose-built subdomain, or stop it from using your domain.

“A forwarded message fails SPF”

That is expected in many forwarding flows because SPF evaluates the server that delivers the message to the final recipient, not necessarily the original authorized sender. DKIM is designed to provide a second authentication signal that can survive forwarding when the message remains intact.

For mail you control, make sure DKIM is enabled and aligned. For mail you receive, do not treat one SPF failure in isolation as proof of malicious mail; evaluate the full authentication results and the receiver’s handling context.

Email authentication records for agencies, SaaS teams, and multi-brand companies

The larger your stack, the more important domain architecture becomes. A single root domain with every vendor sharing one SPF record and one undifferentiated sending identity is difficult to audit and risky to change.

Consider a deliberate subdomain model:

This does not mean every brand must use many subdomains. It means every mail stream should have a clear owner, a documented provider configuration, working aligned authentication, and a monitoring process.

For agencies, authenticate the client’s domain rather than using the agency’s shared sending domain whenever the platform supports it. For SaaS companies, make custom-domain authentication a documented onboarding process. For multi-brand organizations, manage each visible From: domain independently; a perfect DMARC record on the corporate domain does not automatically authenticate mail from a separate consumer brand.

A practical rollout checklist

Use this sequence to reduce disruption:

1. List every sender that uses your domain or subdomains.
2. Inspect live headers from each sender to document current SPF, DKIM, and DMARC results.
3. Publish or repair SPF with one record per relevant envelope domain.
4. Enable DKIM for every sender and verify the actual d= domain is aligned where needed.
5. Publish DMARC with p=none and a mailbox or service for aggregate reports.
6. Review reports and investigate unknown sources. Classify each as legitimate, broken, obsolete, or abusive.
7. Fix alignment, especially for marketing, transactional, and support platforms.
8. Move to p=quarantine when legitimate mail is consistently authenticated.
9. Move to p=reject only after you have confidence in the inventory and ongoing monitoring.
10. Re-audit after changes to vendors, domains, merger activity, new products, or new sending applications.

The success condition is not merely seeing three DNS records in a control panel. It is seeing every legitimate sending stream produce DMARC-aligned mail in real recipient headers, while your reports show that unauthorized sources are no longer able to impersonate the domain successfully.

Conclusion: treat authentication as domain ownership

Email authentication records connect a domain’s public DNS to its real-world sending systems. SPF defines authorized delivery infrastructure, DKIM gives messages a verifiable signature, and DMARC ties those signals to the identity recipients see and gives you a path from visibility to enforcement.

Start with accurate sender discovery, use vendor-provided DNS values rather than generic copies, verify messages in real inboxes, and monitor DMARC reports before enforcing. Done well, the result is stronger protection against spoofing, clearer ownership of every mail stream, and a dependable technical foundation for deliverability.

FAQ

What email authentication records do I need?

At minimum, configure SPF or DKIM for domains that send mail. In practice, use SPF, DKIM, and DMARC together: SPF authorizes sending infrastructure, DKIM signs messages, and DMARC checks aligned authentication for the visible From: domain and provides policy and reporting.

Is DMARC required if I already use SPF and DKIM?

DMARC is what connects SPF and DKIM to the visible sender identity and gives domain owners a way to request quarantine or rejection of spoofed messages. Major mailbox providers have sender requirements that make DMARC especially important for bulk mail, but it is valuable for any domain that wants meaningful anti-spoofing protection.

Can I have multiple SPF records?

No. Publish one SPF TXT policy for a given domain. Combine legitimate mechanisms into one record, and keep the record within SPF’s DNS-lookup limit. Multiple SPF records can lead to a permanent SPF error.

Why does DKIM pass but DMARC fail?

DKIM can pass for a signing domain that is not aligned with the visible From: domain. Check the DKIM header’s d= value. Configure your provider to sign with your domain or an aligned subdomain, or ensure aligned SPF passes instead.

How long should I use p=none before p=quarantine or p=reject?

There is no universal number of days. Keep p=none until your DMARC reports cover a representative business cycle and every legitimate sender is identified and passing aligned SPF or DKIM. The right trigger is evidence from your mail streams, not a calendar deadline.