[{"data":1,"prerenderedAt":190},["ShallowReactive",2],{"publication:en:P062":3},{"meta":4,"copy":17,"relatedArticles":153,"terms":182,"term":183,"resourceParent":184,"glossaryParent":187},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":15,"preparedOn":16},"P062","\u002Fblog\u002Femail-spoofing-domain","article","someone is sending emails from my domain","Someone is sending emails from my domain: what to check","Someone sending emails from your domain? What to check","Distinguish forged From addresses, lookalike domains and compromised mailboxes. Learn what message headers and DMARC can establish before changing business email settings.",[13,14],"\u002Fservices\u002Femail-domains","\u002Fservices\u002Fcorporate-email","2026-10-04","2026-10-30",{"intro":18,"sections":19,"checklistTitle":95,"checklist":96,"faq":103,"sources":113,"links":124,"cta":148},"If someone appears to be sending emails from your domain, first distinguish a forged display name, a lookalike domain, a forged From address and a compromised legitimate account. These situations need different checks. Preserve an original example and use trusted receiving evidence before changing DNS or concluding that your mailbox was hacked.",[20,48,57,62,77,85,90],{"title":21,"paragraphs":22,"table":25},"Check what is actually impersonating the business",[23,24],"A message can show the company's name while using an unrelated address. It can use a similar-looking domain that the business does not own, forge an address at the genuine domain or come through a legitimate account or connected sender. A screenshot of the visible sender alone cannot distinguish all of these possibilities.","Ask the recipient to preserve the original message through an approved process. Do not click its links or forward it widely with private information intact. Record when it arrived, the apparent sender and the action requested. If the message asks for a bank-account change or urgent payment, verify through an independently known contact before acting.",{"caption":26,"headers":27,"rows":31},"Different symptoms, different starting points",[28,29,30],"What appears in the message","What to investigate","Why DMARC alone is not the whole answer",[32,36,40,44],[33,34,35],"Company name, unrelated address","Display-name impersonation","The protected business domain may not be used",[37,38,39],"Similar domain spelling","A separately registered lookalike","Your policy does not control another owner's domain",[41,42,43],"Genuine domain, untrusted sending route","Authentication and alignment evidence","A visible From address can be forged",[45,46,47],"Legitimate authenticated account","Account, application and sending activity","Authentication does not prove the account is uncompromised",{"title":49,"paragraphs":50,"sources":53},"Use message headers from a trusted receiving path",[51,52],"Headers can show how the message travelled and what the receiving system evaluated. SPF, DKIM and DMARC results refer to particular identities and conditions. The administrator needs to understand the trusted receiving boundary; an arbitrary Authentication-Results line inside a message is not automatically trustworthy.","Keep conclusions specific. A DNS record currently visible to a public checker does not prove how a previous message was evaluated. A failed result can also affect a legitimate but misconfigured sender. Gather the original example, relevant times and the receiving provider's evidence, and redact unnecessary content before sharing the case.",[54],{"label":55,"url":56},"RFC 8601: interpreting Authentication-Results","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8601.html",{"title":58,"paragraphs":59},"Check legitimate accounts and sending applications separately",[60,61],"If there are unfamiliar sign-ins, rules, application grants or messages actually sent from the account, involve the authorized administrator in an account-compromise response. Changing only DNS records does not revoke every active session or connected application. The response should also address recovery controls and the trusted device used to administer the account.","Conversely, an apparently forged message does not prove that an employee mailbox was accessed. Avoid resetting every account or deleting business senders without evidence. The useful decision is which observation supports which next check, with the uncertainty recorded rather than filled by the first plausible explanation.",{"title":63,"paragraphs":64,"sources":67},"What authentication can improve",[65,66],"SPF describes permitted sending sources for the relevant envelope identity. DKIM validates a signature associated with a signing domain. DMARC evaluates the visible From domain's alignment with a passing SPF or DKIM route and communicates domain policy. Configure these around the business's actual senders, including websites and external tools.","A move toward enforcement should follow inventory, message checks, report review and a plan for exceptions. The current DMARC standard is RFC 9989 from May 2026. Do not rely on a copied legacy configuration or imply that publication of reject stops every kind of impersonation. Recipient handling and legitimate account activity remain separate issues.",[68,71,74],{"label":69,"url":70},"RFC 7208: Sender Policy Framework","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc7208.html",{"label":72,"url":73},"RFC 6376: DomainKeys Identified Mail","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc6376.html",{"label":75,"url":76},"RFC 9989: DMARC, May 2026","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9989.html",{"title":78,"paragraphs":79,"example":82},"Avoid making legitimate business mail the collateral damage",[80,81],"Map employee mail, CRM, billing, support and website notifications before changing authentication. A source not recognized in a report needs investigation, not automatic authorization or removal. Check the appropriate provider configuration and a representative message for each important route, including functions that run only periodically.","Record what changed and how to reverse it if the agreed checks fail. A successful employee message does not cover an invoicing integration. Likewise, a valid authentication result does not guarantee inbox placement; receiver rules, reputation and message characteristics can affect delivery. Google and Microsoft guidance is specific to their services and applicable sending patterns.",{"title":83,"text":84},"Illustrative diagnostic decision","A recipient sees your company name but the actual address is on an unrelated domain. Your business-domain DMARC policy is not a direct control over that sender's domain. Preserve the example, address the impersonation through suitable channels and review payment-verification practice without treating it as proof of mailbox intrusion.",{"title":86,"paragraphs":87},"If a payment or data disclosure may already have happened",[88,89],"Stop further action and contact the appropriate financial, account or information owner through a known route. Keep timestamps, transaction references and the original communication for the authorized responders. Do not rely on contact details supplied in the suspicious exchange, and do not resend a payment or expose more information as a test.","Reporting, notification and recovery options depend on the jurisdiction, provider and facts. This guide does not set a global legal deadline or promise that funds can be recovered. Technical authentication work can support prevention, but it does not replace an urgent financial response or qualified legal advice where needed.",{"title":91,"paragraphs":92},"What to include when requesting technical help",[93,94],"Provide the genuine domain, mail platform if known, type of symptom and whether a trusted administrator has found unusual account activity. Describe the requested action without sending passwords, verification codes or a complete customer email thread in the enquiry form. An original message can be shared later through an appropriate agreed route.","CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide, with a focus on websites, mail and digital-infrastructure dependencies. We can clarify a scoped authentication or access task within the services described on this site. Authentication work, account investigation and urgent financial action have different owners and should be coordinated according to the facts.","Before changing your domain policy",[97,98,99,100,101,102],"Identify which name, address or account is being impersonated.","Preserve an original message through an appropriate channel.","Use authentication evidence from the trusted receiving system.","Investigate account activity separately from domain policy.","Verify payment changes independently and escalate actual losses promptly.","Map legitimate senders and acceptance checks before enforcement.",[104,107,110],{"question":105,"answer":106},"Does an email with my address prove that my account was hacked?","No, the visible From address can be forged. Investigate the original message and trusted authentication evidence, then examine account activity where the facts justify it.",{"question":108,"answer":109},"Will DMARC stop a similar domain from impersonating us?","Your policy applies to use of the domain it protects under recipient evaluation. It does not give you control over a separate lookalike domain. That scenario needs an appropriate impersonation and business-verification response.",{"question":111,"answer":112},"Should we block every source we do not recognize in a report?","First determine whether it represents a legitimate business system, an indirect mail path or an unauthorized source. Both automatic authorization and indiscriminate removal can be harmful.",[114,115,116,117,118,121],{"label":55,"url":56},{"label":69,"url":70},{"label":72,"url":73},{"label":75,"url":76},{"label":119,"url":120},"Google: sender requirements and authentication","https:\u002F\u002Fsupport.google.com\u002Fa\u002Fanswer\u002F81126?hl=en",{"label":122,"url":123},"Microsoft: configure DMARC","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Femail-authentication-dmarc-configure",[125,128,130,133,136,139,142,145],{"path":126,"label":127},"\u002Fservices\u002Fdmarc-spf-dkim","Map senders and configure authentication",{"path":13,"label":129},"Business email security scope",{"path":131,"label":132},"\u002Fblog\u002Fspf-dkim-dmarc-explained","How the authentication mechanisms differ",{"path":134,"label":135},"\u002Fservices\u002Faccess-2fa-audit","Strengthen account access and recovery",{"path":137,"label":138},"\u002Fblog\u002Femployee-offboarding-access","Review access when a person leaves",{"path":140,"label":141},"\u002Fcontact","Discuss the specific symptom",{"path":143,"label":144},"\u002Fblog\u002Fmicrosoft-365-account-compromise","Respond to suspected Microsoft 365 account compromise",{"path":146,"label":147},"\u002Fglossary\u002Fbec","Separate business email fraud from domain spoofing",{"title":149,"description":150,"button":151,"type":152},"Identify the impersonation before choosing a technical fix","Describe the domain and symptom without forwarding secrets or private message content. We will clarify the relevant scope.","Discuss domain impersonation","check",[154,162,167,175],{"id":155,"path":156,"title":157,"description":158,"category":159,"artwork":159,"order":160,"publishedOn":161},"P059","\u002Fblog\u002Femail-spam-diagnosis","Business emails going to spam: diagnose the delivery path","Diagnose business email submission, rejection, delay and spam placement. Compare actual messages, authentication and receiver feedback before changing DNS.","email",89,"2026-09-24",{"id":159,"path":131,"title":163,"description":164,"category":159,"artwork":159,"order":165,"publishedOn":166},"SPF, DKIM and DMARC Explained","SPF authorizes sending infrastructure for the envelope-sender domain. DKIM lets a receiver verify a domain signature. DMARC requires a successful SPF or DKIM result aligned with the visible From domain. These mechanisms help authenticate domain use; they do not guarantee inbox placement or prove that a message is trustworthy.",105,"2026-04-23",{"id":168,"path":169,"title":170,"description":171,"category":159,"artwork":172,"order":173,"publishedOn":174},"P060","\u002Fblog\u002Fspf-too-many-lookups","SPF too many DNS lookups: find the evaluation path before changing it","Diagnose the SPF term limit and nested includes. Map authorized senders, distinguish permerror from temporary failures and test provider-supported fixes.","servers",81,"2026-09-14",{"id":176,"path":177,"title":178,"description":179,"category":159,"artwork":159,"order":180,"publishedOn":181},"P070","\u002Fblog\u002Fwordpress-form-email","WordPress contact form not sending email: trace every stage","Trace form submission, notification generation, provider handoff and receipt. Test sender identity and replies, distinguish spam placement and protect enquiry data.",73,"2026-09-02",[],null,{"path":185,"label":186},"\u002Fresources","Website security resources and templates",{"path":188,"label":189},"\u002Fglossary","Cybersecurity glossary for small businesses",1794134058697]