Our company owns the domain somecompany.com and uses an external email provider emailemailprovider.com to send emails. The email provider recommends to delegate a subdomain for them to automatically handle SPF / DKIM / etc. email authentication mechanisms. So we added this in our DNS zone:

Since then, we are able to send emails through their API without falling in the SPAM folder of the recipients, and set the From header to any address like user@em.somecompany.com, user@somecompany.com or user@other.somecompany.com. Note that the Return-Path header domain is still em.somecompany.com in all 3 cases.

I get how it's possible to authenticate user@em.somecompany.com with our setup, but I don't get why the 2 other FROM addresses are considered valid by the recipients.

I vaguely understand the difference between the Return-Path header and the From header, but if the company's subdomains were not owned and managed by the same entity, couldn't this lead to serious authentication flaws?

A common misunderstanding is that SPF and DKIM actually prevent spoofing (of the FROM domain). Both can be used to authenticate the domain that they are checked against. For SPF that is the Return-Path and for DKIM it is the domain used in the d= tag within the signature. These domains do not have to align with the FROM domain AT ALL. For protecting the FROM domain against spoofing, please see my answer.
– ReintoDec 18 '19 at 20:22

2 Answers
2

As you mentioned SPF only authenticates the Bounce Address, a.k.a. Return-Path. By keeping the same bounce address for all emails sent, the email always passes SPF. The use of this bounce address is used to perform bounce-handling by your email provider. Additionally, they can now manage your SPF record for this subdomain you delegated.

DKIM

Since you delegated the subdomain by NS record, the email provider can now also create DKIM selector records in the zone _domainkey.em.somecompany.com. So now they can sign messages for you from the domain em.somecompany.com used in the d= tag in the DKIM signature.

DMARC

There actually is a standard way to authenticate a FROM address domain and it incorporates both SPF and DKIM. It demands that one of those mechanisms passes the check AND aligns with the domain used in the FROM address. There are two possible ways in which to align. Either

Strict - The domain used for SPF or DKIM must be exactly the same as the domain in the FROM address, or;

Relaxed - The domain used for SPF or DKIM must share the same organisational domain used in the FROM address.

These alignment modes for SPF and DKIM are controlled by the aspf and adkim tags, respectively. When these tags are omitted from a DMARC policy record, they default to relaxed mode.

The DMARC record must be configured for each domain that needs to be protected against spoofing. At a bare minimum, the DNS TXT record should include the version and policy tag, e.g. "v=DMARC1;p=reject;"

If I read the spec correctly, the Mail Delivery Agent's DMARC module will check DMARC records on _dmarc.<AuthorDomain>, where <AuthorDomain> is the domain used in the FROM address (and fallback to the organizational domain if different). So, when I send an email from user@somecompany.com, the MDA will check _dmarc.somecompany.com (no fallback as it is the organizational domain), and if a DMARC record exists, the specified policy is then enforced. _dmarc.em.somecompany.com is only checked when the FROM address is user@em.somecompany.com.
– Maxime RossiniDec 19 '19 at 8:59

That is absolutely correct. The setup you describe where you delegate a subdomain sounds familiar to me. I can imagine that the email provider hosts its own DMARC record. So, basically, DMARC directly protects the FROM domain.
– ReintoDec 19 '19 at 18:54

They are not considered valid or invalid by the recipients. They are simply being treated as maybe/maybe not spam as there is no associated SPF record to say otherwise. The content of the email is likely evaluated and not considered spammy, so delivered.

I think the heart of the question may be an incorrect assumption that SPF/DKIM is required for email. Its not - although having it can boost delivery.

I understand SPF/DKIM is not a requirement for emails to be delivered. SPF/DKIM do not authenticate the From header, but the Return-Path header (and IP address of the original sender). Plus, the emails I send/receive are definitely authenticated through SPF/DKIM, according to my webmail client's logs (gmail). The email provider took care of configuring the SPF/DKIM DNS records for me in the delegated subdomain.
– Maxime RossiniDec 4 '19 at 18:29

What I don't understand is why there isn't a standard way to authenticate FROM address domains, considering it's the main information the average user will use to determine who sent the email in the first place. Gmail's spam filter obviously has custom rules to determine if a specific email should be considered spam (based on FROM address and many more things), but couldn't part of the problem (sender authentication and authorization) be solved by requiring some form of FROM address domain authentication?
– Maxime RossiniDec 4 '19 at 18:42