Answering Your Webinar Questions: Risk-Free DMARC Enforcement

It can help, but DMARC alone doesn’t fix forwarding because SPF breaks and DKIM often gets modified. The reliable solution is to preserve DKIM and/or enable ARC on the forwarding servers. That’s what improves Gmail delivery the most.
In forwarding scenarios, DKIM is more reliable than SPF, because SPF will always fail once the message is resent by another server. As long as DKIM is configured correctly and passes both authentication and alignment, DMARC can still pass, and the emails can be delivered successfully.

You can’t publish or enforce DMARC for those domains; only the domain owner can. So your DMARC policy applies only to your own business domain.

DMARC is set in your domain’s DNS, so it works the same even if your email is hosted with Bluehost. As long as Bluehost is included in your SPF and DKIM is enabled for your domain, your legitimate emails will pass DMARC.

Move to DMARC enforcement when your reports show that all legitimate sending sources are passing authentication — ideally with DKIM alignment (and SPF where possible) — and any remaining failures are only from unauthorized sources.

BIMI works on top of DMARC. You must have DMARC enforcement (p=quarantine or p=reject) for BIMI to display your logo in supporting inboxes. You can read about BIMI here in this article.

Move to DMARC enforcement once all legitimate mail sent through SendGrid (and any other approved services) is consistently passing SPF and especially DKIM with alignment, and you have dedicated DMARC RUA and RUF addresses in place to receive and analyze the reports so you have a complete overview of all sending sources and can properly authenticate and align them before enforcing.

Forwarding typically breaks SPF, so as long as the original message keeps a valid, aligned DKIM signature, it will still pass DMARC and be delivered; only forwarded messages without aligned DKIM (and no ARC to vouch for them) are likely to be rejected.

This can be resolved by checking this article.

SPF and DKIM are the foundation of DMARC — without them properly configured, DMARC cannot pass, and enforcement will break legitimate mail. To better understand this topic, check out this article on SPF, DKIM & DMARC.

If your domain never sends email, the best practice is to set its DMARC policy to p=reject and ensure valid RUA and RUF addresses so you can monitor and receive reports of any spoofing attempts.

Most mail servers don’t send DMARC failure (RUF) reports because they contain sensitive information, including the From/To addresses and the full content of the email, which could expose users’ data and compromise message integrity, so major providers generally don’t support them.

As long as your RUA and RUF addresses are included in your DMARC record, you don’t really need to manually review the raw XML reports. EasyDMARC will automatically parse them into a human-readable dashboard that shows all sending sources, pass/fail status, and alignment, so you can monitor everything without opening the XML files.

The SPF all qualifier determines how strict receiving servers should treat mail from IPs not listed in your SPF record. Read more here in this article.

SPF Pass/Fail results depend on two factors: Authentication and Alignment.
Authentication: Confirms that the sending IP or host is authorized to send email for the domain listed in the SPF record. For example, if an email is sent from example.com, SPF checks whether that IP is included in the SPF record for example.com.
Alignment: Ensures that the domain in the visible From: header aligns with the domain used for SPF authentication (MAIL FROM / Return-Path). For instance, if the email’s From: address is [email protected], the SPF authentication must pass for a domain that matches or is properly aligned with example.com to satisfy DMARC.

DMARC reports are XML documents that provide information about the authentication status of DMARC, SPF, and DKIM. Sign up for free and start reading your DMARC reports with EasyDMARC’s report analyzer.