We've recently started using DMARC for our domain, and we're doing our best to get everything passing before we switch from p=none to p=reject. Unfortunately, the information we're getting from the aggregate reports that various domains are sending us is not always sufficient for us to figure out DMARC failures. We thought we could address this by putting an "ruf" field into our DMARC record, but after doing that, we're still not getting any failure reports. After further research, I think this is because failure reports aren't actually generated for p=none, i.e., they're only generated for p=reject.
Is that correct? If so, that seems like a real problem that I don't know how to get past. Here's the thing... I'm pretty sure most of the DMARC failures we're seeing are actually legitimate email messages, but like I said, we don't have enough information from the aggregate reports to be able to figure out why they're failing DMARC. There's a chicken-and-egg problem here: I can't get enough information to figure out what's going wrong with these emails until I enable p=reject, and because I don't want to bounce legitimate emails, I can't enable p=reject until I've figured out what's going wrong with these emails. So, what am I supposed to do? Also, another thing I'm confused about from reading the available information about DMARC is whether, once we enable p=reject, we'll get copies of /all/ messages that are rejected due to DMARC failures, or whether instead it's up to the discretion of each receiving MTA to decide whether to generate a failure report. If the former, then at least theoretically, we could enable p=reject briefly, collect some sample DMARC failure reports to troubleshoot, then disable p=reject, troubleshoot the failures, and forward them on to their intended recipients, so no email ends up getting lost. But if it's up to the discretion of the MTA whether to generate a bounce report, then even if we only enable p=reject for a short period of time, we could end up causing legitimate emails to be lost, and we'd really rather not have that happen. Thanks, Jonathan Kamens
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
