See how DMARC, SPF, and DKIM work interactively
learndmarc.com
learndmarc.com
In the meantime, I'm hoping to avoid yet another subscription service. Any suggestions?
You can use it for free for personal (non-commercial) domains. Paid tiers (starting at 19 EUR/month) also offer additional services such as MTA-STS policy hosting and BIMI asset hosting.
Disclosure: I'm the founder of Mailhardener.
A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:
1. produces a "pass" result
Of course the receiving mailserver is free to enforce a strict DKIM&SPF requirement aside the DMARC check/spec. If your question is why that would be necessary, I'd love to hear the reason aswell
Based on the RFC, for the rest of possible SPF configurations (more strict), SPF record would be enough. But I am guessing based on the RFC document and my experience.
dkim : the email is signed (using a private key) with a unique signature, the receiving server can validate the DKIM signature by running a DNS query to search for the public key for that domain .
dmarc : publish a policy on how emails that does not satisfy the above condition above (spf & dkim) should be handled (quarantine, reject) and optionally sends you a report on who send/tried to send emails on the behalf of your domain
Edit : I misread your question... it is odd indeed that only satisfying one condition is enough for a pass...
But this is from the RFC document, so it may be that in practical cases things are more nuanced.
SPF is enough to prevent spoofed source of SMTP envelope, but not for From: spoofing. (applying it to From: address would reject any forwarded mail, which probably isn't desired)
DKIM ensures legitimacy of From: address, and works correctly with forwarding. But DKIM itself doesn't specify whether you should require DKIM signature. (ADSP record allows to specify that, but it wasn't deployed nearly at all)
DMARC record is used to specify unambiguous policy, and it passes when either SPF is aligned with From: address, or there's valid DKIM signature. Thus DKIM+DMARC is enough to prevent spoofed mail, but SPF is usually kept in case some servers still don't support newer methods. SPF+DMARC would also prevent spoofing, but will also reject forwarded mail.
Note that SPF+DKIM without DMARC doesn't really protect against spoofing, because SPF checks only envelope address, and you cannot tell whether DKIM signature is required.
If I'm not tech savvy I'd easily fall for it. If I go down the rabbit hole and view all message headers I see it's fake, but why does the mail client show it as if it's from Facebook in the first place? It's a huge attack vector still present for many non-tech savvy users.
(For clarity I'm not talking about the sender name which can be anything that is free text. I'm talking about the "apparent" from field which does not reflect the actual sending address and looks perfectly legit as if from @facebook.com)
In my own (rather WIP, wouldn't really suggest anyone else use it yet) client I display both if different - which should make it clear even if the content isn't stereotypically crap and obvious spam/phishing (to a more technical user).
If you read the RFCs, it was intended for use cases like 'from Mr Blah, but sent by his secretary, reply to his secretary'. Primarily legitimately used today almost like that I suppose - with mailing list / support case management type software being the 'secretary'.
So maybe I'm half answering my own point - Gmail et al. show `From` because it's usually friendlier to a non-technical user, it's who it's 'really' from, not confusing them with 'who is this Intercom.io' or whatever. But.. surely it's worth showing both, to help in the phishing cases as you say.
Let's say fishysenders.com tries to fake an email on behalf of johnsmith@company.com (and thus, dmarc alignment fails)
Gmail would say "From: johnsmith@company.com via fishysenders.com"
So technically this is a very solved problem. Facebook unfortunately is very much the exception. It is pretty much impossible to convince entities like your bank to sign their emails.
Certainly if you have a DMARC policy of p=reject and then you screw up your outbound, then your DMARC policy becomes relevant, but not in a good way. I don't see the harm in not having one.
Email providers such as outlook and gmail think otherwise. Your emails will not be reliably delivered to them because you are missing a restrictive DMARC policy. Emails send without a DMARC policy are less trusted by default and more likely tagged as spam.
Big providers like Gmail, Outlook, etc all have a scoring system for sender IP addresses and hostnames. The longer your IP and hostname behaves properly, the more credit it will get.
I imagine starting a new mail server with new ip addresses/hostnames may be more difficult.
If you've ever gotten loads of mailer-daemon bounces for emails that you didn't send, then a spammer has been using your address(es) in the "From" header.
This eliminates that problem.
N.B. - I used to work for a Very Large ESP.
NB - I work for a large messaging security company.
Dmarc is increasingly required to get past spam filters. And doing dmarc properly requires a reporting service. Either you run servers or use a hosted service like the one that created this page. That's fine for some business, but putting a cost on dmarc reporting and then making dmarc a heavy signal in spam filters is a huge pain for some scenarios.
It's not highly expensive, but on non monetized side projects it can frustrating how how much the internet expects you to have dmarc on every domain now.
Google support is just brushing people off with the link and they are somewhat right, because a lot don't have anything set. There is also a bit of black magic with spam filters that Google support will never tell you about because it will be just like SEO, someone will use it to pass filters.
That said, there are multiple other reasons that your email can be qualified as spam by the spam filter. Like sending out email from one domain and having links to another domain in the body as an example. Not having "unsubscribe" links on mass mail. There are legitimate reasons to throw email to spam because some companies get their infra or "contact us" forms hacked.
In the end users can be annoying because they might not understand what "this is spam" button means for the sender - they just think your mail was annoying and they did not expect it and press that and you are qualified as a spam.
Using DMARC is more about having a process for properly adding new senders once everything is setup than it is a long term cost sink. You can keep a reporting service around to monitor your email delivery, but you don’t have to at all.
I've never tried, but but wondered if it would it be enough to simply use a inbox@whatever inbox you have setup, most likely gmail on your domain (don't know what google calls that now workplace idk)?
In cases where it's super unlikely someone would try to send as the domain so it's just setting it up to check a box for deliverability.
DKIM isn't hard to manage, SPF can be a pita. Although IP blocks are a very sensible network management tool (cloud provider and customers hate it), it is more difficult to administrate than setting up some domain keys. It will have to be managed whenever anything that is sending mail changes its public IP address, which very often happens if you host it in the "cloud".
This is incorrect.
DMARC requires nothing but an email address to send reporting to. It costs nothing to implement and there are open source [0] solutions out there if you want to monitor the reporting being sent.
And to clarify - the reporting you're getting back from a DMARC is either an aggregate or a forensic report. There aren't many email providers that actually send forensic reporting anymore, the 99% of reports you'll get are aggregate in nature.
And finally, remember that if you don't have a policy of "REJECT" set on your domains, DMARC isn't doing you a whole lot of good.
This is also incorrect. Reporting (rua/ruf) are optional.
> if you don't have a policy of "REJECT" set on your domains, DMARC isn't doing you a whole lot of good.
With "quarantine" failing emails will go to spam, which is plenty good enough in most cases.
I never stated RUA/RUF were required.
My intent was to state that the parent I was replying to implied "services" or "servers" were required to collect and/or process reporting. One can simply collect reporting and process offline or simply consume manually. I do this, personally, for a few low email volume domains I own. You can't get RUA/RUF any other way.
> You can't get RUA/RUF any other way.
There are free services that provide analysis, such as https://dmarc.postmarkapp.com/, although arguably you still need an email address to sign up. But it is another, actually useful, way to receive the reports.
> There are free services that provide analysis, such as https://dmarc.postmarkapp.com/, although arguably you still need an email address to sign up.
YES. That's what I said.
well done and keep the good work.
Nice site - I feel like it doesn't good a job at teaching these just validating, which is fine just the name is kinda misleading.
I often use https://www.mail-tester.com.
I tried it with all three of my domains.
It's interesting that two of them didn't have full DKIM/DMARC support, even though they are paid mail services.
I'll have to check, and see if there is anything that I can do.
I seldom have issues with bounces or spam-suckers, but I have had a couple, with those domains.
My mac.com domain was green, all the way.
Nice work.
It would be very nice if more header information would be exposed so you exactly see what is taken into account.
The major bug bounty websites like Bugcrowd and HackerOne have rules about duplicate and non-actionable submissions, which usually hurt the researcher, for example, by decreasing their reputation points. After the first couple of submissions, I got curious, so I decided to open a separate category for these submissions where I asked every researcher to provide a proof of concept of the attack. Unsurprisingly, none of them were able to. Some of them closed their own submissions, and the others lost some reputation points due to Bugcrowd or HackerOne’s intervention.
Somehow, we did not receive more submissions about DMARC, SPF, or DKIM after that, which was interesting, as if all the researchers were working together to spam as many bug bounty programs as possible with the same “vulnerability” to get easy money from unsuspected program managers.
i sent an email and the result was
"Final verdict:
No specific action is taken by DMARC regarding the delivery of the message. This usually means the message will be delivered successfully. Keep in mind that other mechanisms such as a spam filter can still reject or quarantine a message."
make note that it took me no more than an hour at most in my first attempt to set up the email server including learning about dmarc, spf and where to put that into my email server as well as in the domain registrar.
i have had no problems for the past almost a year and i am confident there shouldn't be many problems in future.
I did have trouble with the results aligning correctly on mobile.
Looks very nice!
The library supports typing animation and changing colors. You can easily create the same interactive console.
If you're interested I can create a demo for this.