Is It Legit? 10 Real Domains Attackers Borrow

Table of Contents The short answer is yes. Google owns scoutcamp.bounces.google.com and c.gle, and Microsoft owns forms.cloud.microsoft. Every domain on this list is real, owned by the company you think owns it, and used every day for ordinary business mail. That answer still doesn't tell you whether the email in front of you is safe. A real domain tells you which platform sent the message. It says nothing about who was sitting at the keyboard on the other end of that platform. We see these exact domains in our Attack of the Day teardowns, and the teardowns people find most often in search are the ones where attackers sent phishing through infrastructure that passed every check. Most of those visitors arrive after searching some version of "is this legit?" So here are the direct answers, domain by domain, plus what to check when the domain is real and your gut still says no. Key takeaways - Every domain below is legitimate and owned by the company it names. - Attackers use these platforms because the mail passes SPF, DKIM and DMARC, and the links scan clean. - Authentication proves which system sent a message. It can't prove the account behind it belongs to who it claims. - Check the Reply-To, the account behind the notification, whether you've ever dealt with that sender, and what the link asks you to do. - Allow-listing these domains exempts the exact mail these campaigns ride in on. Quick answers: who owns these domains and how attackers use them | Domain or sender | Owner | Legitimate use | How attackers abuse it | What to check | |---|---|---|---|---| | scoutcamp.bounces.google.com, sc-noreply@google.com | Return-Path and sender for Google Search Console notifications | Search Console notices that push a sign-in at accounts.google.com | Do you manage a site in Search Console, and did you expect this? | | | c.gle | Short links inside Google's own emails and support content | Rides along in genuine Google notifications, so scanners clear it | What is the email carrying the link asking you to do? | | | forms.cloud.microsoft | Microsoft | Microsoft Forms on the newer cloud.microsoft domain | A real Microsoft Form, built by the attacker, collecting your details | Who created the form, and why do they need what it asks for? | | message@adobe.com, postoffice.adobe.com | Adobe | Acrobat sharing notifications and Adobe's link redirect | A real Acrobat share sent as a colleague | Did that colleague share a file with you? | | mail.hellosign.com | Dropbox (Dropbox Sign) | E-signature requests | Signing requests from an attacker-made account on a days-old domain | How old is the requester's domain? | | docsend.com | Dropbox | Tracked document sharing | A real share notification with the Reply-To pointed elsewhere | Where do replies actually go? | | message-service@sender.zohobooks.com | Zoho | Invoices sent from Zoho Books on a customer's behalf | Real Zoho invoices carrying an extra link | Do you owe this vendor, and what is the extra link? | | sendgrid.net, ct.sendgrid.net | Twilio SendGrid | Email delivery and click tracking | Wrapping the attacker's link in a trusted tracking redirect | Where does the redirect land, and does the From domain match the brand? | | sf-notifications.com | ShareFile (Progress) | ShareFile system notifications | Spoofed From address on mail that never touched ShareFile | Did SPF, DKIM and DMARC pass? | | lu.ma, luma.com | Luma | Event invitations and registrations | A fake event sent through real Luma mail, replies routed to Gmail | Does the event exist outside Luma? | | link.edgepilot.com, Mimecast rewrite hosts | AppRiver (OpenText), Mimecast | Rewriting links so a security product can check them at click time | Phishing links that arrive already wrapped and look "checked" | Where does the link end up? | The domains, one at a time Is scoutcamp.bounces.google.com legit? Yes. scoutcamp.bounces.google.com is a Google-owned bounce domain. It appears as the Return-Path on Google Search Console notifications, which come from sc-noreply@google.com. Mail using it passes SPF, DKIM and DMARC for Google because Google sent it. In the campaign we caught, Search Console notifications arrived through that exact pipeline: a valid google.com DKIM signature, Google's own sending IPs, and Microsoft's spam filter scoring it SCL 1. Every button went to search.google.com, an accounts.google.com sign-in flow, or a c.gle short link. Link scanners returned clean verdicts with screenshots of real Google pages. (Full teardown.) What to check: If you don't manage a website in Search Console, you have no reason to receive these. If you do, open Search Console yourself instead of clicking through. Is c.gle legit? What is c.gle? Yes. c.gle is a Google short-link domain. It runs on Google's network (AS15169) and Google's own name servers, and you'll mostly see it inside Google's notifications and support content. In the Search Console campaign above, c.gle links sat next to the accounts.google.com sign-in links and resolved to real Search Console and Google support pages. That's why scanners passed them. A c.gle link is only as trustworthy as the email carrying it. What to check: Judge the message carrying the link. Who sent the notification, did you expect it, and what does it want you to sign in to? Is forms.cloud.microsoft legit? Yes. forms.cloud.microsoft is Microsoft Forms on Microsoft's cloud.microsoft domain. Microsoft has been moving Microsoft 365 apps there, running alongside older addresses like forms.office.com (Message Center notice MC1066944). Because it's newer, plenty of people and plenty of allow-lists don't recognize it yet. In our case, employees at a global industrial manufacturer received a Microsoft Forms invitation to an "Adobe Acrobat Pro Usage Assessment." It came from a compromised Microsoft 365 account at a real technology services firm, passed SPF, DKIM and DMARC, and earned Microsoft's highest composite authentication score. The "Start now" button opened a real Microsoft Form that the attacker built. Its first required field asked for full name and location. (Full teardown.) What to check: Any Microsoft 365 user can create a form. The domain tells you where the form lives. It tells you nothing about who wrote it. Ask why a "survey" needs the information it's asking for. Is message@adobe.com legit? What about postoffice.adobe.com? Yes. message@adobe.com sends Adobe Acrobat sharing notifications, delivered through Amazon SES on Adobe's authorized infrastructure and signed with Adobe's DKIM keys. postoffice.adobe.com is Adobe's link-redirect host for those emails. We saw a K-12 school district staff member receive an Acrobat share "via Adobe Acrobat" showing a colleague's school email address, with a document name built to look like a classroom resource. SPF, DKIM and DMARC passed for adobe.com. The Open button routed through postoffice.adobe.com with the destination encoded in a token that scanners couldn't read until someone clicked. The same lure reached four mailboxes. (Full teardown.) What to check: Acrobat sends a share notification to any address an account holder enters. Confirm the share with the colleague over Teams, Slack or a phone call before you open anything. Is mail.hellosign.com legit? Is HelloSign a scam? Yes, HelloSign is legitimate. It's the e-signature product Dropbox now calls Dropbox Sign. mail.hellosign.com is its sending domain, and signing links go to app.hellosign.com. In the case we analyzed, an attacker registered filesignportal.com nine days before the attack, opened a HelloSign account under it, and sent an HR payroll signing request. SPF, DKIM and DMARC passed for mail.hellosign.com, and every link went to Dropbox-owned domains. The attacker's only infrastructure was a nine-day-old domain behind privacy-shielded registration. (Full teardown.) What to check: Dropbox delivered the request. Look at who made it, and check the requester's domain age. Your HR team doesn't send payroll paperwork from a domain that didn't exist two weeks ago. Is DocSend legit? Yes. DocSend is a document-sharing and tracking service that Dropbox acquired in 2021. Share notifications come from DocSend's own infrastructure and link to docsend.com and dropbox.com. A forensics consulting firm received a DocSend share notification that passed SPF, DKIM and DMARC, with every link pointing to real DocSend and Dropbox pages and a Microsoft spam score of 1. One header was off. The Reply-To sent responses to a law-firm domain behind privacy-shielded registration that we couldn't verify. (Full teardown.) What to check: Before you reply, look at where the reply goes. Most mail clients show the address when you hit Reply, and your security team can pull it from the headers. Is message-service@sender.zohobooks.com legit? Yes. Zoho Books sends invoices on behalf of its customers. According to Zoho's documentation, when a customer's domain has no DKIM record, Zoho Books replaces the From address with message-service@sender.zohobooks.com and keeps replies pointed at the customer's own address. We saw a past-due invoice from a drone services vendor, sent through Zoho Books four months after its stated due date. The PAY NOW button went to a legitimate Zoho payment domain. The payload sat below the invoice: a Google Drive folder link that standard Zoho invoices don't carry. (Full teardown.) What to check: That generic sender address means every Zoho Books customer looks identical in your inbox. Ask accounts payable whether you work with the vendor named on the invoice, and treat any link other than the payment button as the real question. Is sendgrid.net legit? What is ct.sendgrid.net? Yes. SendGrid is Twilio's email delivery platform. ct.sendgrid.net is its click-tracking host. SendGrid wraps the links in its customers' emails so clicks get logged, then redirects to the real destination. Companies that set up link branding get the wrapper on their own domain instead. A finance employee at a healthcare education institution received a pixel-perfect SendGrid account notice warning that API sending needed to be restored. The only button went through a real ct.sendgrid.net tracking URL. The envelope sender belonged to a compromised U.S. window manufacturer, the one visible mismatch in the whole message. (Full teardown.) What to check: A ct.sendgrid.net link tells you the sender uses SendGrid, and thousands of legitimate companies do (so do some attackers). Check where the redirect lands, and compare the From domain to the brand the email claims to be. Is sf-notifications.com legit? Yes. sf-notifications.com is ShareFile's notification domain. ShareFile's own firewall documentation tells admins to allow-list *.sf-notifications.com for system notifications, security communications and invoices. Our case ran the other direction from every other example here. A shared-folder notice used mail@sf-notifications.com as the From address, but it never traveled through ShareFile's mail servers, so it failed SPF, DKIM and DMARC at delivery. The link pointed at a real, live ShareFile-hosted subdomain, so scanners cleared it, and the Reply-To went to an unrelated insurance-industry domain. The same lure came back weeks later, and again months after that. (Full teardown.) What to check: Real domains get spoofed too. Here, authentication results do answer the question: a DMARC failure on a domain that publishes a DMARC policy is the signal. An allow-list entry that trusts the From domain alone would have waved this one through. Is Luma (lu.ma) legit? Yes. Luma (lu.ma, also luma.com) is an event hosting and ticketing platform. It sends invitations and confirmations through Amazon SES on its own authenticated domains. An attacker created a fake "AI Engineering Conference 2026" on Luma, complete with an event page and a real venue, and the invitations went out through Luma's own pipeline. SPF, DKIM and DMARC passed. The Reply-To went to a personal Gmail account. (Full teardown.) What to check: Anyone can publish an event on Luma. Look up the event and the organizer outside the platform, and check where replies go. Even your email security vendor's links are real domains Two more domains get searched for the same reason: link.edgepilot.com and Mimecast's rewrite hosts (protect-us.mimecast.com and url.us.m.mimecastprotect.com). Both are legitimate. link.edgepilot.com is a link-protection rewriter run by AppRiver, now part of OpenText. Mimecast URL Protect rewrites links onto its own domains so it can check them when someone clicks. If you see either one, a security product rewrote that link. That's all a wrapper tells you. It doesn't tell you the destination was safe, and it doesn't tell you whose security product did the wrapping. In one case we saw, a phishing link passed through EdgePilot, then Barracuda's link protection, then a throwaway domain before reaching a Google Docs phishing page (teardown). In another, every button in a fake law-firm settlement email went through a Mimecast-wrapped URL to a lookalike domain registered 22 hours earlier (teardown). Employees have learned to read a wrapper as "already checked," and attackers know it. Why passing SPF, DKIM and DMARC doesn't settle it SPF checks that the sending server is allowed to send for the domain. DKIM checks that the message wasn't altered after the domain signed it. DMARC checks that those results line up with the domain in the From line. All three answer one question: did this domain's infrastructure send this message? For every platform above except ShareFile, the answer was yes. Google sent the Search Console mail. Adobe sent the Acrobat share. Dropbox sent the HelloSign request. Each platform did exactly what it was built to do, on behalf of an account the attacker created or compromised. That's how these campaigns get past filtering that leans on reputation. Sender reputation is perfect because the sender is Google or Microsoft. Link reputation is clean because the links go to Google or Microsoft. The content passes because it's the platform's own template. The evidence sits in context: who's asking, whether they've ever asked before, and what they want you to do. What to check when the domain is real - Read the Reply-To. The DocSend and Luma messages looked perfect until you saw where replies went. A notification platform has no reason to route your reply to Gmail or an unrelated law firm. - Find the account behind the notification. The platform is the delivery truck. Identify the customer account that loaded it: the signature requester, the Zoho Books customer, the form creator, the event organizer. Then check that account's domain age and history. - Ask whether the relationship exists. Do you manage a site in Search Console? Do you owe this vendor money? Has this colleague ever shared an Acrobat file with you? A first-time sender on a trusted platform deserves more scrutiny than a regular one. - Look at what the link asks for. Signing in, entering personal details and granting access are what attackers want. If a survey wants your name and location, or a notification wants your password, stop there. - Verify out of band. Go to the service directly by typing the address or opening the app, or contact the sender through a channel you already trust. Don't use any link, phone number or reply address from the email itself. What this means for allow-lists and your filtering stack When users keep reporting legitimate Adobe or SendGrid mail, the reflex is to allow-list the domain. The trade looks cheap: fewer false positives, fewer tickets. It also exempts the exact mail these campaigns ride in on, from the one layer that might have looked twice. If business-critical platforms need allow-list entries, scope them tightly. Match the specific sender, require authentication to pass, and keep behavioral checks running on everything that gets through. Catching these campaigns takes detection that reads behavior instead of reputation. Our Adaptive AI flagged the cases above on signals like a first-time sender relationship, a Reply-To that doesn't match the sender, intent that doesn't fit the notification type, and the same lure hitting other organizations across a community of 36,000+ security professionals across 18,000+ organizations. None of those signals rely on the domain looking bad. We publish a new teardown like these every day in Attack of the Day. Frequently asked questions Is an email legitimate if it passes SPF, DKIM and DMARC? Not necessarily. Passing means the domain's own infrastructure sent the message. When attackers abuse platforms like Google Search Console, Adobe Acrobat or Dropbox Sign, the platform sends the email for them, so all three checks pass. Judge the message by the sender relationship, the Reply-To and what it asks you to do. What is scoutcamp.bounces.google.com? scoutcamp.bounces.google.com is a Google-owned bounce domain used as the Return-Path for Google Search Console notifications sent from sc-noreply@google.com. It's legitimate, but attackers have triggered real Search Console notifications to push sign-ins, so confirm you manage a site in Search Console before acting on one. What is c.gle? c.gle is a Google short-link domain that runs on Google's network and appears inside Google's own emails and support content. The domain is legitimate. A c.gle link is only as trustworthy as the email carrying it, so judge the sender and the request instead of the link. Is forms.cloud.microsoft a real Microsoft domain? Yes. forms.cloud.microsoft hosts Microsoft Forms on Microsoft's newer cloud.microsoft domain. Any Microsoft 365 user can create a form there, including attackers using compromised accounts, so a real Forms link only tells you where the form is hosted. Check who built it and why it wants your information. Why do I get emails from sendgrid.net? SendGrid, owned by Twilio, delivers email for thousands of companies, and ct.sendgrid.net is its click-tracking redirect. Seeing it means the sender uses SendGrid. Attackers use it too, so check where the redirect lands and whether the From domain matches the brand in the email. Should I allow-list trusted platforms like Adobe, Dropbox Sign or SendGrid? Avoid allow-listing whole platform domains. Attackers send phishing through these exact platforms, and a domain-wide allow-list exempts that mail from inspection. If you need an entry, scope it to a specific sender, require authentication to pass, and keep behavioral analysis running on allowed mail. How do attackers send phishing from legitimate domains? They open an account on the platform or compromise an existing one, then use a normal feature to trigger the email: sharing a file, creating a form, sending an invoice, requesting a signature or publishing an event. The platform's own servers send the message, so it carries valid authentication and clean links. What is link.edgepilot.com? link.edgepilot.com is a link-protection rewriter run by AppRiver, now part of OpenText. It rewrites links so they can be checked at click time. A wrapped link tells you a security product touched it. Check the final destination before you trust it. Explore More Articles Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.