Fel 550 5.7.1 ”Message rejected due to DMARC policy” – orsaker och åtgärder

Vad felet betyder

Den mottagande e-postservern avvisade ditt meddelande eftersom det underkändes i DMARC-utvärderingen mot den policy som din egen domän har publicerat. Typiska texter i returmeddelanden:

550 5.7.1 Email rejected per DMARC policy for yourdomain.com
550 5.7.1 Unauthenticated email from yourdomain.com is not accepted
554 5.7.5 Permanent error evaluating DMARC policy

Till skillnad från leverantörsspecifika fel kan DMARC-avvisningar med 5.7.1 komma från vilken mottagande server som helst – Gmail, Microsoft, företags e-postgateways, andra verksamheter. Koden 5.7.1 ensam visar inte att DMARC är orsaken: kontrollera att returmeddelandets text nämner DMARC. Med p=reject begär du avvisning när meddelandet inte klarar vare sig SPF eller DKIM med domänöverensstämmelse (alignment). p=quarantine begär att meddelandet hanteras som misstänkt; mottagarens egna regler kan ändå leda till avvisning.

Felet är vanligt i ett särskilt scenario: ett företag går över till p=reject, och en legitim utskickstjänst som aldrig hade korrekt alignment börjar få sina meddelanden avvisade. Det är inte policyn som är fel – det var inventeringen som var ofullständig.

Varför du ser det

• En legitim avsändare saknar alignment. Tjänsten skickar riktig e-post åt dig, men dess meddelanden klarar varken SPF eller DKIM med din domän. Det fungerade innan policyn skärptes; nu gör det inte det.
• Vidarebefordrad e-post. En mottagare vidarebefordrar ditt meddelande automatiskt; SPF går sönder på vägen, och om meddelandet inte var DKIM-signerat underkänns den vidarebefordrade kopian i DMARC hos den slutliga mottagaren. E-postlistor ger upphov till samma mönster.
• E-post från underdomäner utan egna poster. E-post från invoices.yourdomain.com ärver organisationsdomänens policy via sp= eller standardarvet, men avsändaren klarar varken SPF eller DKIM med alignment mot den synliga Från-domänen.
• Du utsattes för domänförfalskning (spoofing) – och DMARC fungerade. Om det avvisade meddelandet inte alls är ditt är felet ett tecken på att systemet gör sitt jobb: någon förfalskade din domän och mottagaren stoppade meddelandet. Dina mottagna DMARC-aggregatrapporter kan visa källan.

Så åtgärdar du det

1. Avgör om den avvisade e-posten är legitim. Jämför uppgifterna i returmeddelandet med de utskickstjänster du vet att du använder. Om meddelandet inte är ditt behövs ingen åtgärd – spara det som belägg för att policyn gör nytta.
2. Om den är legitim, åtgärda avsändarens alignment:aktivera DKIM-signering med din domän i tjänstens inställningar (DKIM kan klara vidarebefordran om det signerade innehållet är oförändrat) och/eller lägg till tjänsten i SPF med korrekt alignment.
3. Kontrollera underdomänerna. Kontrollera den synliga Från-domänen, SPF:s kuvertdomän och DKIM:s signeringsdomän för varje tjänst. Publicera poster där dessa identiteter kräver det och kontrollera vilken DMARC-policy underdomänen ärver.
4. Om legitim e-post avvisas, överväg att tillfälligt använda p=none medan du åtgärdar avsändarna. Granska din avsändarinventering, meddelandehuvuden och mottagna rapporter innan du återgår till p=quarantine eller p=reject. Den äldre procentstyrningen med pct= har tagits bort i RFC 9989 och begränsar inte tillämpningen på ett tillförlitligt sätt. Testläget t=y begär en nivå mildare hantering, men äldre mottagare kan ignorera det.
5. Läs dina aggregatrapporter löpande. De visar vad rapporterande mottagare har sett. Täckningen kan vara ofullständig och rapporterna fördröjda. Kombinera dem med din egen inventering av avsändare och tester av meddelanden.

Den större bilden

En strängare DMARC-policy kan minska direkt förfalskning av din domän. Den stoppar inte snarlika domäner, förfalskade visningsnamn eller kontokapning. Börja med rapportering, kontrollera legitima avsändare och skärp policyn när underlaget stöder det. Merula hjälper dig att bedöma konfigurationen och mottagna rapporter, men garanterar inte leverans och kan inte identifiera varje avsändare.