DMARC requires valid, aligned SPF / DKIM. The policy specifies what to do when it fails to pass. A p=reject policy will prevent spoofed emails from the domain to providers enforcing DMARC. SPF itself doesn't stop spoofing since it does not need to be aligned with the FROM header.
Conversation
Also, hardly anyone enforces SPF even with a hard fail policy, but it's not particularly relevant since it doesn't have to be aligned. SPF will pass with a spoofed FROM header as long as MAIL FROM (relay) passes. DMARC is what makes SPF and DKIM actually function properly.
2
1
2
In order of importance: set up DMARC and then set up DNSSEC. Fill in the NULL MX records and SPF records for every A and AAAA record if you want to go the extra mile. It's much less important than the baseline. DMARC will still reject spoofed mail without having an SPF record.
2
1
2
I agree that null MX is a good thing.
But I think it is only needed for domains that are having unauthorized email sent on their behalf.
DMARC makes it easier to identify these domains. At least from recipients that participate in DMARC.
1
I think you're misunderstanding the purpose of null MX. It declares that the domain doesn't receive email. It doesn't forbid sending mail. It can still be used to send email that passes DMARC verification via either a valid and aligned DKIM signature or valid and aligned SPF.
1
I’m aware of the difference.
If I have control of my DNS, and the firewalls / daemons in the A / AAAA records that don’t have a null MX, and MXs for the parent names are properly configured to not handle mail for child domains, then what is the effective difference?
1
Email for child names is still not going to come in.
So I don’t see a need for a null MX other than to indicate to others to not send email to the domain.
I’m not aware of a sufficient number of receiving servers rejecting email if they can’t send to the purported source.
2
Again, you're misunderstanding the purpose of null MX. It announces that a host does not receive email. It is not about sending email. The purpose of null MX is so that a mail server can immediately see that it cannot send email to that host. It doesn't need to keep retrying.
3
The RFCs recommends that mail servers attempt to send email repeatedly over a substantial period of time if they get a soft failure. Attempting to connect to a mail server via the A or AAAA record and not finding one is a soft failure. It could just be temporarily down.
2
Agreed.
That is a /recommendation/. It also effects the would be sender. It has no real effect on the would be recipient.
Save for minimal bandwidth of rejected connections or rejected emails at parent domain MXs.
1
The effect is that is someone accidentally sends an important mail to someone@subdomain.example.com but you don't receive mail there, they immediately get an error, and can realize their mistake and send it to the correct address. Saves some resources for the sender too.
I agree that it’s convenient.
But convenience is not a good reason to invest a finite amount of time for each and every FQDN.
Besides, I would personally be more inclined to have proper MX records that route the email through a central system to divvy it out as appropriate.