this post was submitted on 26 Apr 2025
43 points (100.0% liked)
Cybersecurity
0 readers
14 users here now
An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!
Rules
Community Rules
- Be kind
- Limit promotional activities
- Non-cybersecurity posts should be redirected to other communities within infosec.pub.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@ikidd@lemmy.world People are not reading. You are not reading.
SPF, DKIM and DMARC are not relevant. Those are instructions to the receiving servers which are not the ones sending the bounces. The receiving server is telling the sending server, based on these DNS records, that it will not accept the message. It refuses them. Period. No bounce message.
The sending server then, as a courtesy, lets the sender know, solely based on the FROM: address, that the email could not be delivered, as one by one messages.
There are no DNS records or configurations that control this. The SMTP server follows the protocol which is to inform the FROM: address, as a courtesy, that the email was not accepted. It is the sender. It does not look at SPF, DMARC, and DKIM rules. That is only what the destination server uses.
The point is that if an SMTP server is respecting RFC7208 then you don't get those bounces if you have the records. Which is most SMTP servers now.
My hotmail inbox says that Miocrosoft must then not be a member of the "most" group.
Maybe Hotmail, I couldn't say about freemail domains, but I get dmarc reports for recipients on Office 365 hosted domains all the time and have for years. They were one of the earliest adopters, since I've had a dmarc policy for my domains for over a decade.
DMARC reports are sent by the receiving server, which is not the server sending the bounces. They are reports sent to the domain owner. SPF, DKIM and DMARC are only meant as tools to protect the domain owner and indicate when an email should not be accepted.
These bounces are coming from the sending server whose email attempt got rejected by the receiving server. They are NDRs which are not covered by SPF, DKIM, or DMARC.
The sending server is informing the FROM: address, as a courtesy, that the email could not be delivered, even when the sending server knows the FROM is likely fraudulent. This has nothing to do with SPF, DMARC or DKIM and is a different protocol.
Argue with Google, not me: https://support.google.com/mail/thread/209018675/my-sent-email-box-is-filling-up-with-bounce-emails-and-emails-i-did-not-send-my-inbox-is-fine?hl=en
Is the recipient server drops or quarantines spam instead of rejecting it (which is standard best practice), the sending server will never know, and won't send a message back to the sender.
DMARC has only 3 options. Ignore, reject or quarantine. There is no "drop" instead of "reject". And anything other than an "ignore" will cause a reject from the receiving server back to the sending server who will then inform the FROM address that the email was not delivered.